I like your paradigm shift.
> Date: Mon, 24 Oct 94 13:52:31 EDT
> From: justin@dsd.camb.inmet.com (Mark Waks)
> Subject: Re: VRML MUD's & Interaction
> One useful way of looking at this: the Web (in its VRML incarnation)
> provides the *static* database underlying our "world". The "MUD" is
> in charge of dealing with *dynamic* data -- the elements of the world
> that have changed from this baseline, within a particular context.
> (And there may be an indefinite number of these "contexts".)
Yes, exactly. The static copy, I was calling that the "master copy".
> The room
> is fetched, and the VRMUD connection is established. My client tells
> the server where I am in the room; the server tells it that there
> isn't anything else different here.
I.e. the server beams you the master copy, and adds its two cents:
"by the way, there are no delta changes to the that master copy I
just sent you."
> I wander out into the "hallway" that I've built, and step out of that
> into a lounge that's been set up over at MIT. As I do so, my client
> continues to send updates on my position back to the server, which
> continues to say that there's nothing interesting going on here.
Yes, Good. Precisely. When you first enter the hallway, (or when you
first glimpse it through a doorway??) your client askes the server for
a complete copy of the hallway to be sent over. Then, as you move around,
you keep the server informed (hmm bandwidth ...). The server stays
quiet, because it knows that your copy of the world is still accurate,
in sync, valid.
> As I step into the lounge, my client sends that information to the
> server. The server checks that room and finds that others on this MUD
> (say, my friends Rick and Gideon) are already in this room. It sends
> back a set of tranformations to the room: Chair 1 has been moved and
> turned slightly, and Gideon (whose "image" is sent) is sitting in it;
> similarly, Rick is in Chair 2; and there is a board game spread out on
> the table. My client takes this information, uses it to transform the
> scene graph in some fashion, and displays this synthesized
> information.
Yes. This sounds good, but I got confused every time I went to think
about this. There is a problem of exactly how do you do this.
I guess there are two ways of doing this:
1) Changed-Internal model. This is what I was thinking when I wrote
the last note. The server keeps track of changes by actually
internalizing the composite/container objects (aka Inventor "separator
nodes") that are different. Thus, when you entered an occupied room
for the first time, you got a copy of the server's current,
internalized version.
2) Static-plus-Deltas model. This seems to be what Justin is suggesting.
When you first enter an occupied room, the server sends you the complete
copy of the unoccupied room, plus a list of delta changes/modifications
that need to be applied. (It got the master copy by going out to the
file system, and relaying whatever was out there).
I kind of like 2) better. Here's why:
-- Reversibility. You can sort of "go back", or at least know what the
changes were. With 1), you know that there are changes, but you don't
really know what they are. All you know is that the current model
differs from the static model. With 2), you have some hope of
distinguishing the changes you want to keep (Justin's "long-term changes")
from those you want to throw away.
-- Minimal updates. If something changes in 1) while you are in the room,
1) will send you the whole new scene graph (i.e. the result of all
previous changes, together with the most current change). But 2) will
send you only the change -- less network traffic -- less work by the
client.
-- No new function. We already knew that we need some sort of edit (or at
least add/delete) protocol for VRML, so that MUD clients can send info to
MUD servers about thier location, appearence, etc. Well -- why not
have the server respond with the same edit-protocol? In fact, simple
servers could be almost no-ops -- they re-broadcast any incoming changes,
and keep a log of old changes (which are forwarded to newcomers, so they
can get up-to-date). And thats it. Is that easy to implement, or what?
> It requires a *very* intelligent client,
> but I don't think that's an unreasonable thing to require, these days.
?? How so ??
The client has to be able to eat the edit protocol, as well as issue it.
I don't see that this is the hardest part -- pruning, culling, visualizing
complicated rooms with lots of stuff in them, with decent performance,
is the hard part.
> This model for MUDs implicitly recognizes that as the priority --
> the "MUD" isn't defined as a collection of rooms, but instead as a
> collection of people in the universe of the Web.
Hmmmm.
> Linas mentions the alternate model, where each site is essentially
> a "MUD" for its own rooms, and we define a protocol for handing
> people off from one "place" to another. I don't like this as much,
> mainly because I don't think it's as practical. A lot of sites
> aren't going to want to put up MUD-like interactions
Actually, no. I was thinking out loud about how to solve the
load-balancing problem -- what happened when one site (or mud)
got really, really popular -- how to off-load some of the vistors
onto aliased sites (that look just like this one, but execute on
a differnet physical machine). It occurs to me now that there
are a bunch of different solutions for that; It's not clear that
this matters much, anyway.
> BTW, don't take any of this as an assertion that this scheme is
> easy to implement. There are some real problems to address.
Name them.
The tough nut is the need to invent an add-delete protocol.
My understanding of inventor, which may be flawed, is that an
add-delete protocol for inventor would be tricky. Someone,
prove me wrong. Likewise, my understanding of web-oogl is that
such a protocol is easy. But I understand web-oogl even more
poorly, so I'll say -- someone -- prove me right.
What else is there?
> I don't think it's any *harder* than the 1-to-1 mapping version,
> where each site runs a "MUD" for its own rooms, and I think that
> there are powerful advantages to it.
Well, that's not what I thought I was describing, but OK, I don't
mind ...
--linas