I second. We should use gzip. No tokenized or binary formats. The
spec should suggest that servers drop a few digits of precision from
floats (optionally; photorealistic models may need IEEE precision.)
Let me try to explain why I think we need things called "copper" and
"teapot", because several people seem to not be seeing the benefits:
[email protected] (Mitra):
>I guess I'm saying that the URL is (in the absence of URNs) the name of
>the object. Much better than arbitrary names like "teapot" because they
>also say how to get the generic object if I don't have it cached, or on my
>CDROM etc.
I think that we need to have both. The likelihood of me having cached a
red teapot is MUCH greater than the likelihood of me having cached
http://foo.org/eating/RedTeapot.wrl
Thus VRML needs to be extended to contain a keyword based description,
such as "teapot detailed 'Paul Revere' silver elvey". That way, a cache
can contain a teapot, silver teapot, and my teapot, all at once, instead
of just foo.org's SilverTeapot.wrl, which is all that a regular
(existing http type) cache will contain.
At the very least, a field such as
keywords <keywords>
(in a URC type format) should be strongly recommended for each object.
I would like to add that I thing the whole concept of something like
http://vrml.com/eating/container/serving/RedTeapot.wrl, where this is
the canonical, centralized location for The Red Teapot is repulsive.
The Internet (the main driving force behind VRML, IMO) is supposed to be
decentralized, and NOT fee for service based. I (we, I hope) DO want a
system where VRML.com can go down and it will be all right. A VIRTUAL
"dependable registry" can be achieved without recourse to a centralized
(almost certainly fee-based) "dependable registry".com!