I also note that at least on the ISDN side, there is a lot of
incompatible equipment out there, so whether you actually get
compression or not depends on whether or not you own the same
brand name as your internet provider.
I don't really know how compatbile all those v.whatever modems are,
and whether they really do kick into compressed mode. My own 14.4
modem never seems to get above 11 kbits/sec during anon ftp.
Note also, gzip offers benefits even on ethernet segments ...
and saves file space to boot.
>Does this mean that gzip-style data compression (beyond tokenization) should
>be:
>
> a) On demand (which requires scripting on the host side)
> b) Required (less efficient with V.42bis, an important issue nowadays)
> c) Not implemented (less efficent in most situations)
d) optional. Consider the following dirt-simple algorithm:
WWWInline "foo.vrml" ->
browser looks for foo.vrml // foo.vrml is uncompressed ASCII format
if (foo.vrml not found) {
look for foo.vrml.gz
if (foo.vrml.gz) {
gunzip foo.vrml
} else {
bad link
}
}
If you support this natively, then I think you can avoid having to
fiddle with the .mime.types; ... I dunno, I've never written a browser.
It would be coolest if this decision was made on the server side,
and the browser could handle whatever it got back. I.E. browser
asks for foo.vrml, server realizes that there is no such, but that
there is is a foo.vrml.gz. The server ships back the gz, while
the browser says "gee I got a gz, lets gunzip it", even though
the borwser didn't originally ask for a gz.
--linas