[Standards-JIG] JEP-0138 (Stream Compression): A case for LZO / even better algorithms
Andreas van Cranenburgh
andreas at unstable.nl
Thu Nov 3 04:07:44 UTC 2005
On Wed, Nov 02, 2005 at 01:16:53PM -0700, Peter Saint-Andre wrote:
> Hi Andreas,
> Thanks for the information. I don't think JEP-0138 will recommend one
> algorithm over another except for making zlib mandatory to implement
> (mostly because it is in common use). Some quick research on LZO does
> indicate that it is very fast, however, it seems to be a library that
> uses multiple algorithms rather than a well-documented algorithm itself.
> For instance, see the LZO documentation and FAQ:
> I think we'd prefer to reference a somewhat standardized algorithm (as
> we do for zlib and lzw) rather than just a library.
If that is indeed true then I'll just invite people to experiment with
LZO in Jabber .
Thanks for following up, by the way.
> Am I missing something here?
Could be, but then again: I certainly am :)
What I assume is that there's a clear seperation from the algorithm (LZO) and
implementation (lzop). Eg. note the use of case. But this might only
be superficial, and perhaps when you look better it's not such a neat
algorithm, but simply a collection of things. I suppose it's rather
adaptive, to the data being fed to it. If Jabber prefers to have
scientifically peer-reviewed algorithms etc., then I understand that.
How does it work with such standards, do I violate JEP-0138 if I use LZO
right now in a theoretical python script? Either way, I'll try  just
for the fun of it.
 I'm going to setup an OpenVPN server with TLS keys to allow multiple
connections on one port/daemon; just to see how scalable that is. I'll
also enable LZO, anyone with a slow connection is invited to try using
unstable.nl's jabber server (ejabberd), through this LZO tunnel.
Encryption of the VPN can be turned off, since it will be for Jabber
which uses TLS. Mail me for details (ie. being a beta tester).
Andreas [ http://unstable.nl | xmpp:andreas at unstable.nl ]
[ callto:ils.seconix.com/andreas at unstable.nl ]
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Standards