Based on experiments I did last year I'd disagree with this but anyway.....
> Not all compressions are created equal :) For most applications I don't
> think this is significant compared to the baud rate - as long as the
> application could decompress more than 1.8K of compressed text per
> second it shouldn't matter.
>
> Sending compressed VRML over a modem using compression *may* result in
> a performance decrease, but that's more a quality of implementation issue
> for the modem - this is true for other compressed media as well (mpeg,
> jpeg's, etc).
Okay, without having done any of the experiments I proposed this is
what my gut feeling is:
1) for large uncompressed files 5meg+, compressing them (gzip will do just
fine) is going to out do anything the modem can compress. Even if it
took gzip an entire minute to uncompress the file (it won't take that
long).
2) for files 1meg and less, compressing them with gzip and sending them
through that way will be a tough call, but I the gzipped version
outdoes the modem compress by a minuet (the closer to 1meg the better
gzip will do). BUT! around 700K and less I bet modem compression
starts to be looking might fine. And yes, people who have their
modem always compress data via SLIP and transfer lots of images and
stuff are taking a hit (in the past, when I would feed UUCP sites news,
I would compress the news with compress and turn off modem compression
for the session).
Based on point 2, and my agreement that Gavin might be correct in assuming
that most VRML worlds are going to consist of a lot of Inlines, makes
me wonder how likely that we see the average VRML page over 1 meg.
Again, we don't know any of this since people aren't generating VRML
scenes everyday -- Which Was The Entire Point Of The Original Message.
--------------------------------------------------------------------------------
Neophytos Iacovou Distributed Computing Services
University of Minnesota 100 Union St. SE
email: [email protected] Minneapolis, MN 55455 USA