I think it might be a good idea. At this point, I am seeing *immense*
confusion, due to all the press that VRML is getting. People are seeing
the term "VRML", and reading all of cyberspace into that. I think that
that's dangerous; if we let that mindset pervade us, we're apt to wind
up designing ourselves a huge, unwieldy language. Better to get our
terms straight, and call a spade a spade. At the moment, we're sort of
at Cyberspace 0.5 -- VRML 1.0 is about halfway towards something that
really deserves the name "cyberspace". I'd agree that VRML 2.0 (or
*possibly* 1.1) will probably be the basis for Cyberspace 1.0...
I'll suggest generally what I said in my newsgroup name vote: I really
think we do *not* want to use "vrml" in the name of the newsgroup. We
should go for something like "comp.vr.net" or "comp.cyberspace", which
can serve as the basis of a hierarchy for all of the below issues...
>A rose by any name, the overall architecture is The most important
>design decision. What are the big pieces? or even features? Try these:
>
> - VRML for geometry, perhaps some geometric behavior
Check. VRML is essentially the "static basis" for Cyberspace, the way
that we describe the static characteristics of *things*.
> - Distributed Object/Event System (keeps clients in sync)
> (VES, VRTP, DIS, ...)
I'm still unconvinced that this is needed, but this all ties in with
the whole VRMUD concept (which is essentially the flip side of the
same coin). But that's a big issue unto itself, relating to how the
dynamic side of cyberspace is stored...
Tied in with this is the issue of multi-user cyberspace -- how do
users see each other? I *suspect* that this is part and parcel with
the above, although to some degree that depends on implementation...
> - Sound
Which *is* argubly tied into VRML, at least in that describing how
a sound ties into a scene is arguably a part of that scene's static
characteristics. I'd say that sound has both static and dynamic
characteristics, depending on what you're doing with it, and these
might well want entirely different solutions...
> - Interactivity (See Paul Buchard's great issues page:
> http://www.geom.umn.edu/hypernews/get/interactive/index.html)
> - Scripting ability
I wouldn't say "scripting" per se at this point, but rather "behaviour".
Scripting is one way to achieve behaviour (and, IMO, the likeliest way
to do so), but I don't think we've locked that down as the only way yet.
I think that "behaviour" also covers Interactivity, but I haven't had
time to dig through Paul's page yet, so I'm not sure we're using the
terms identically.
> - Synchronizer in client.
Not sure what you mean by this one.
> - Simulation environment (i.e. physics based modelling)
Tied into both behaviour and VRML, I suspect...
-- Justin
Random Quote du Jour:
"You now have a knife sticking out of a large hole in your intestines,
with them having a tendency to move outwards."
-- Dave Kaplowitz