> The HTML part compresses fine but that does not a web page make. Take a
> drive that nothing but web pages on it and tar it into your favorite
> compresser and see what kind of compression you get. For the 530mb of
> input we get 360mb output which is only about 1/3 and this is far better
gee, ours compressed at about a 90% savings! how you say? read on...
> compression than Stac will give on the fly. And this is because the bulk
> of the data is not HTML but pre compressed images and sound files that the
> compressors will do nothing with.
Ahh, yes, BUT, and that is a very big but.... What is your company in
business of providing? We provide INFORMATION, gigs and gigs of it. We
spit out lots more text html than we do graphics. So it depends on the
data and the situation.
What percentage of the total html flying around out there do you think is
highly compressible data? I really dont know but I bet alot of it is.
> But you know what? I will take that <1/3 increase if I was offered it for
> free. When the pipe is full any increase is welcome because it would
> decrease latency at that point.
Right! That's another good point. If it is free or cost is little or there
is some way to fine-tune the compression (e.g. dont compress compressed
data) then it would work. The problem with determining whether to
compressor not, is you have to try to compress it (or part of it) first!
To compress or NOT to compress, that is the question... whether to suffer
the slings and arrows of outrageous algorhythms...
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Jake Messinger 713-772-6690 jake@ams.com
Advanced Medical Systems, Inc. jake@uh.edu
9919 S. Gessner #201
Houston, Texas 77071 http://www.ams.com/~jake
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~