> > VRML doesn't quite work yet for MUD-building since it doesn't include
> > synchronous hooks to tie a client to.
>
> Yes, this seems like a deficiency. Certainly something to work on.
Looking back through the archieves you may find me spouting off the benefits
of having an oo type object instantiation/modification/deletion interface
with both synchronous and asynch hooks for binding to any kind of external
language/application/MOO/MUD system. I've previously called this kind of system
a "renderactor" - a rendering and interacting component.
I envision this system as the renderer and interaction parts of a VRML-like
system split out, with a defined API, common across platforms and
implementations. The main reason I think this kind of system is a good idea is
because it lets people who build renderers build great renderers, and lets
people who write parsers, language tools, multi-person interactive spaces
(M**'s), etc, concentrate on them, not on rendering concerns, or how to map a
mouse click into 3-d space. It makes hacking a new 3-d paradigm more plausible
than it is currently.
This kind of approach is a prototyping tool; it lets us experiment with the way
in which we want to interact in cyberspace by building cheap, disposable systems
which people can play with in a short time period. It encourages a mix and match
approach to developing renderers and the code which handles person-person,
server side, and client side behaviours. We could have P-D renderer
implementations, which are upgradable to industrial strenth renderers (a nice
new market for SGI, Temple, et al - yummy), mix and match systems, etc.
This wasn't the direction VRML was ever aimed in; such a thing could probably be
built with parts from a VRML browser, but it isn't VRML and probably shouldn't
be discussed on the VRML list. Another (newly constructed) list would be far
better, and the VRML community (and many others besides) might end up with a
neat, standard, building block, out of that effort.
-- Mike