Specifically, when you use http and the Web, the servers do *not* have
any idea "where" you are. The connection is strictly unidirectional --
your *browser* knows where you are, and queries for pages as you track
around. Those pages are served to you, but once a given service is done,
http stops trying to keep track of you -- if you want more information
from a given service, you need to ask again.
I've been assuming that we will be using http, or something pretty
similar, for vrml. That is, we will follow the same model that the
only responsibility of a server is to send you the information about
a given scene and its object, and once that's done, it can forget
about you and go on to something else.
A properly interactive system, on the other hand, needs to know where
all of the people in it are. If I say something, the server must know
who else is in the room with me, so that they can hear it. This concept
of tracking locations is integral to MUDs, but *very* different from
the Web, where only your local machine knows your "location".
This is why I say different programs for different needs. For
wandering around cyberspace, the best model to use is the Web/http
one, where servers simply send you rooms as you need them. For
interactivity, a more sophisticated system is needed, that tracks your
current position. There's no reason to build both of these into the
same server, and a good argument not to: simplicity and focus. A
system that tries to do one thing usually does that one thing better
than a system that tries to do many can. If we can distribute the
load, let's do so. Let us develop the tools for navigating and
showing the world here, and let others develop the tools for
interacting *in* that world on top of it later...
-- Justin
Random Quote du Jour:
"Insinkerator: Mechanical food-disposal unit based on the principle
of the teenager."
-- Henry Beard