Keith,
It's not anywhere nearly that bad. First of all, we don't need multiple
compression algorithms -- we need one that everyone can use freely.
How is it you figure that?
Different compression algorithms make sense for different data files. There
are generic algorithms as used in compress or gzip. If you try those on
audio or image files they don't work too well. But using an algorithm
tuned to audio or images works fantastically (*sometimes* by losing
information, unfortunately).
This implies, to me, a need for lots of (well, a few anyway) compression
algorithms. Well, maybe only three. Four? (1: generic algorithm for
`everything', 2: audio-specific, 3: image-specific, 4: video-specific).
At least these anyway.
Note that I said `a need for', I am trying to view this from an end-users
viewpoint. S/he will eventually want to ship these various kinds of things
around. Their network managers will appreciate it highly if it is compressed
before shipping. Or maybe their MTAs could have a hook to compress things
that aren't already compressed -- in messages which are to be sent to a
distant place.
Since Keith is, in my opinion, wrong in this assertion his assertion that
"Compressed-BASE64" & etc will not work. This is because what I've argued
above strongly requires the "Compress-alg-{n}-BASE64" style of approach.
What does it hurt to put compression algorithm choice in as an option/value
pair instead of as a modifier to the encoding name?
<- David Herron <david(_at_)twg(_dot_)com> (work)
<david(_at_)davids(_dot_)mmdf(_dot_)com> (home)
<-
<-
<- Where su-b-tlety is taken to an art!