Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!rpi!usc!apple!tahoe!jimi!howlin.cs.unlv.edu!maniac
From: maniac@howlin.cs.unlv.edu (Eric J. Schwertfeger)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Message compression
Message-ID: <1991Apr7.205532.7521@unlv.edu>
Date: 7 Apr 91 20:55:32 GMT
References: <SOLENSKY.91Apr4114120@animal.clearpoint.com> <obz08jq00WCpE4ddc4@andrew.cmu.edu>
Sender: news@unlv.edu (News User)
Reply-To: maniac@howlin.cs.unlv.edu (Eric J. Schwertfeger)
Organization: UNLV Computer Science and Electrical Engineering
Lines: 13

In article <obz08jq00WCpE4ddc4@andrew.cmu.edu>, ww0n+@ANDREW.CMU.EDU (Walter Lloyd Wimer III) writes:

) > is that they need to be able to look at the entire data stream before
) > being able to compress any part of it.  In this case, it would be about
) > the same as running compress yourself and then FTPing the resulting file.
) 
) 
) From empirical evidence, I don't believe this is true.

	It isn't.  I've written LZW compression code before, and it is highly stream oriented.  The hash table is created and updated on both ends on the fly, with only one special case.

-- 
Eric J. Schwertfeger, maniac@jimi.cs.unlv.edu