True, but I think it's a misuse of the technology. Http is fast, but
it's not *really* designed for real-time, particularly the level of
real-time that would be desired for this application. (Ultimately,
we're talking about teleconferencing, needing *huge* bandwidth and
very fast response.)
No, I think the best thing to do is accept that VRML browsers will
serve multiple purposes, and let other tools fill this need. You
could certainly combine VRML with a multi-media MUD, for instance.
The browser (which would need to support both) would log into the
MUD, and keep it informed about which VRML "room" you are in. If
other users of the MUD were in the same room, it would set up a
video link so that you would see the other users there -- each user
would appear in the room at the location of their avatar. Different
need, different program -- just a single browser that can cope with
both. I sincerely believe that this *will* happen if we leave the
option open, and it means that we don't have to wrestle with these
hard issues ourselves.
(There are some cute implications here. For instance, this multi-MUD
might allow partitioning of the space into multiple "conferences", so
that you can have several conversations going on in the same room,
without the participants interfering with (or even seeing) each other.
Once the technology is up-to-snuff, this will be a fun application
to write...)
-- Justin
Random Quote du Jour:
"Agnus Dei was a woman composer famous for her church music."