Gee, that sounds great. If the gzip/PKZIP algorithm is free of legal
entnagelements, as seems to be the case, and is produces reasonably
tight compression without too much CPU, why not go with it? It seems
to me that "several compression algorithms and rules for choosing
among them" can be considered one more complex algorithm.
Furthermore, it seems like producing binary output is more general as
you can encode it as base64 if you need to or not if you don't.
Surely the effort in doing the base64 encoding is not a problem?
Donald
From: John C Klensin <KLENSIN(_at_)INFOODS(_dot_)MIT(_dot_)EDU>
In-Reply-To:
<9303191555(_dot_)AA07314(_at_)skidrow(_dot_)ljo(_dot_)dec(_dot_)com>
I would suggest just going with the most widely used software
compression algorith, PKZIP from the IBM PC world. I don't know
PKZIP is an application program that contains several different
compression algorithms and rules for choosing among them.
gzip, mentioned here some days ago, is interoperable with PKZIP for
compression and decompression of files as are a host of other programs
on a variety of platforms. The algorithms used were released by Phil
Katz (PKWare) and others to the public.
Do note, however, that the encoding used is inherently binary, so one
would need to compress and then apply, e.g., base64 encoding. There
would be obvious large advantages in the email world to have a
compressor that produced nothing but the characters used in base64
directly, rather than going through a compress-and-encode process.
Does this mean we are converging, or just going around in circles?
-john