>> It might well be that the best thing we can do for the data transfer is to
>> compress the files. gzip (gnu zip) compresses the Connaly molecule from
>> 635K to 181K.
>>
>> The text data usually about 8 chars per floating point value. A binary
>> representation is 4 bytes. That is only a factor of 2. A binary version
>> of the Connaly molecule is about 235K. (using Inventor on NT)
Out of this entire discussion, a couple of points have emerged:
a) Tokenization of VRML (with blank removal, et. al.) is good.
b) Compression is good.
c) These techniques will work anywhere, anytime.
While these might be coincident, they may not be.
>*) Q: Should vrml server/client compress/decompress, or should the lan/wan?
> I note that many modems, 14.4 & ISDN, offer compression ... which works
> for text, but not for gif's. Once something is compressed, it can't be
> compressed further. So shipping compressed vrml over an isdn modem only
> ends up chewing through more client-cpu time, without offering any actual
> transmission benefit. So maybe vrml should punt, and let the network
> equipment do its job?
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)
Finally, could we bring this issue to closure quickly? I would very much
like to enfold this technology into TCC's freeware VRML browser; it is
*essential* for anyone who isn't running on a T-1.
Mark
---------------------------------------------------------------
Mark Pesce
General Partner,
The Community Company * tcc@net.org * 415.621.1981
mpesce@netcom.com * http://www.hyperreal.com/~mpesce
I AM * 31 ~ 418 ~ 2012 * That's AL