I ran some tests as well, and while I believe the results for large files,
there is still an open question in mind about compression for small
files/objects.
As Mark said, worlds are likely to evolve to have a lot of pointers to
external objects and textures, allowing the worlds to get smaller. If we
have any kind of dynamic updating, then we are likely to end up moving
fairly small bits of VRML around, for example I add a node to a Group
containing a WWWInline to a teapot.
We could use gzip for this as well, but the time overhead is quite large,
it appears that below around 100 or so bytes there is no improvement, in
fact there is a loss. But for transactions that low, the network and server
latency will be the main factor, however on even slightly larger files, the
load time for gzip (around 0.6 secs on an Indy) will be significant.
The other problem with gzip is going to be on lower end platforms,
launching a seperate ap on a PC is a much more expensive proposition than
it is under Unix, and it might be decidedly non trivial to have browsers
pipe through a seperate decompresser.
- Mitra
=======================================================================
Mitra mitra@kaworlds.com
Worlds Inc (415)281-1308
<http://earth.path.net/mitra> fax (415)284-9483