[dcc2] Multi headers + metadata

[Phoenix Fyrestar]

I agree.  For encryption I think we should standardize on the fastest 
"acceptably secure" encryption method,  blowfish seems to fit this quite 
well.

I'm not entirely sure that we should go with a weak compression algorithm 
however.  While I personally see encryption as a necessary feature that 
should be supported by every client, compression I see more as a nice thing 
that should be incoperated into the standard, but not 100% neccessary.  
Mainly because the lower-memory machines you refer too are unlikely to be 
transfering files large enough for the lack of compression to matter 
signifigantly,  or the slowness of it to really matter signifigantly.

I know gzip allows you set how aggressively compressed a file is.  Could we 
allow the client to specify what level of compression it would like?  for 
example: compression=0...9 where 0 is no compression andn 9 is maximum 
compression.

Having never written any compression software of any signifigant complexity 
before I'm not sure, would this be too difficult to impliment?

On Wednesday 28 April 2004 02:00 pm, Craig Edwards wrote:
> if this is the case the simplest encryption and simplest compression
> methods should be the manditory ones, for slower machines and small-memory
> machines such as PDAs etc.
>
> e.g. blowfish as the minimum encryption type (as this has been proven to
> work on small-memory model and slow processors) and runlength or huffman as
> the basic compression type (however this would still be optional as the
> receiver could still say 'no thanks' to the compression and force the file
> to be sent uncompressed).