ietf-822
[Top] [All Lists]

Re: LZJU90 compression example(s)

1998-09-21 12:22:53
On Mon, 21 Sep 1998, Ned Freed wrote:
I think we should consider LZJU90 as a potential alternative to gzip +
base64.  LZJU90 is certainly much simpler than gzip, although it also
provides significantly less compression.  From what I can tell, both
LZJU90 and gzip are based on LZ77, so the main difference is that gzip
adds huffman coding with optional adaptive tables on top of what LZJU90
does and that gzip is far more widely deployed.

I'm afraid I have a big problem with this. First of all, all the debate  about
compression speed seems to me to be beside the point. CPUs get faster all the
time and there's no indication this will change any time soon. Networks, on 
the
other hand, haven't increased in speed in a comparable fashion and there's no
indication this is going to change either, the promise of xDSL 
notwithstanding.

I agree that performance of the compression algorithm isn't an issue. 
However, code complexity is an issue and LZJU90 is much simpler than
deflate (I observe that available skilled programmer and troubleshooting
cycles are perhaps even more of a scarce resource than network bandwidth
-- one of the key reasons I prefer text protocols to binary).  Those
huffman-encoded huffman tables in deflate make it rather complex (albeit
quite clever).

I don't think LZJU90 should be dismissed out of hand just because
gzip/deflate provides better compression.  This is a classic tradeoff
between complexity and network badwidth usage and deserves serious
consideration.

I'm leaning towards a gzip+4-in-5 solution on the grounds that there is a
widely available well-debugged/tested implementation (zlib).  Another
consideration is that I'd want the good MUA of the future to include an
inline PNG viewer and using gzip/deflate would permit re-use of the
compression code.  It's also my understanding that the only compression
algorithm which has been implemented in conjunction with TLS is
gzip/deflate.  This amount of code-reuse is very attractive.  But somebody
has to write the spec first and I don't have time.

However, there's a lot to be said for a solution which is simple enough
that there can be sample source in the spec.

                - Chris