>Which reminds me of something I've been starting to wonder. Over the
>past several months, there has been a tendency to refer to "1.x" and
>"2.0". I'm just curious -- do people have opinions about what these
>are going to mean? We've got a *huge* wishlist of features stacked up;
>obviously, not all of them are going to get into the next release. I'm
>just wondering whether anyone has given any coherent thought to when
>we're going to declare a "major release" of the language, as opposed
>to a "minor" one. Not critical; just food for thought...
I will be posting on the issues which have been brought before the list
repeatedly as "major" issues for VRML 1.x - these are things we deferred
(with the exception of behavior which is the BIG deal for VRML 2.0) for
expediency's sake. VRML 1.x will be a "major" release, in terms of
functionality, although there will probably be only minor changes/additions
to syntax.
>Check; this makes plenty of sense. However, a suggestion: let's make
>sure we leave room for an expanded keyword set. We're well under 255
>keywords now, but I'm not confident that we will remain so forever.
>I'd suggest a one-or-two byte format, with the high-order bit indicating
>whether it's a one or two byte token. Put the 128 most common keywords
>into 1-byte tokens, and we've got nigh-infinite expansion space for more
>later. We get most of the benefit, with *far* less risk later.
This seems very reasonable; not overdesigning so much as thinking ahead.
It ties into having the DEF parameter use the extra-bit-means-two-bytes -
but I get ahead of myself here. Good recommendation.
>Also -- while we will need a token equivalent to "}" (or something to
>indicate the end of scope of a node), do we need anything for "{"? Or
>can we simply assume that "{" is folded into the node name?
I believe we can; they appear to be in the language for no other reason then
consistency. (Is this true, Gavin?)
>And we should bear expansion in mind. Extension nodes will (by
>definition) not be part of the standard, so they won't have
>predefined tokens. We should chew on how to handle them. We
>could run them in full ASCII, or have some kind of prelude that
>defines (for the duration of the file) the token for that
>keyword, or maybe something else. There are numerous ways we
>could deal, but we will need to choose one.
Perhaps we should have a "DEF range" of tokens that can be dynamically
allocated by the VRML binary-izer. Then we can explore "reference by token"
options.
>Theory and practice war within me. The purist positively shrieks at the
>concept of using such a coarse grain for numbers. The pragmatist points
>out that this is (assuming 1 unit == 1 meter) about 4-millimeter precision
>and a really big range, and may well be good enough for many objects.
[ I am not clear on this (unit == 1 meter) but have thus far kept quiet to
the whole list about this. I have - after two years of thought - determined
that millimeter == 1 unit resolution is almost always the best choice,
because most values are then integer quanities, and motion deltas (which
will become important in VRML 2.0) can be given as byte values, rather than
IEEE floats. This utilizes 4x less bandwidth for the same information.
The resolution of the human eye is "on the order of" one millimeter, meaning
between 0.1 millimeter and 1 millimeter, depending on how bad your eyes are.
My eyes, for instance, are accurate down to about 5 millimeters. On a good
day. ]
>Again, the purist in me finds it inelegant, but it's probably efficient,
>so I'll stifle the argument. Question, though -- how do we translate this
>into our data stream? Is it conceptually a node? (Everything else is, so it's
>probably easier if we remain consistent.) If so, is it a container like
>a Separator (everything in me is FIXED) or does it affect everything after
>it like a Transform (everything after me is FLOAT)? Probably the latter,
>but let's get it clear.
I don't think it needs to be a node at all; this is not a VRML construct,
but rather something that is in the binary file format as a "hint" to the
stream reader. It is a stream token. It is or should be quite invisible to
VRML ASCII.
As for the scope of a FIXED/FLOAT token, it seems reasonable that they
should have Transform-like behavior; until further notice, in the stream,
all numbers are given in the specified format.
>I'm not quite *that* hot on it -- I think we need rudimentary behaviours
>just as much, to make cyberspace *interesting* enough to be worth it.
For the 14.4 modem user who's downloaded their copy of
WebSpace/WorldView/VRML browser-of-the-month it will be the most important
feature of VRML. It's the part they have to deal with as they wait -
AGAIN!!! - for another fat world. It's the difference between 10 seconds
and 10 minutes in some cases; and most often the difference between 1 minute
or 10. And that's the difference between a click and a yawn.
Texture maps will be bad enough (even with JPEG); and we've not really seen
any of those yet - but textures *and* a fat ASCII format will be the death blow.
It'll kill VRML quicker than anything else.
Rudimentary behaviors are already possible with the SWITCH construct; they
are crude, but they will work. Hacking the behavior problem might be a
waste of time; we may want to have a facility for streaming "changes" into a
VRML browser - so that server-side push or MOO can dump "updates" into a
world, but beyond that we should wait for (and start to define the
requirements of) VRML 2.0.
>(And probably some mechanism for connecting worlds better, be it portals,
>CP, both or neither, to make the whole thing *feel* more natural.)
Cyberspace Protocol is the subject of the a posting set for Thursday.
CP is neither dead nor forgotten; we just never needed it before.
Thanks for the excellent comments.
I'll keep a document outlining this proposal as it takes shape.
Mark Pesce
VRML List Moderator