The case that pops into my mind right away is this : I've got twenty people
to update, and half-way through sending out updates, something happens (my
net link has problems, my browser crashes, whatever). Now you've got two
sets of browsers with two (possibly very different) views of the world.
>I suspect we're not going to have any choice in this. Consider: when
>VRMUDs get serious, we're going to want full-conversation audio. Do we
>*really* want all that audio funnelling into the server, and then back
>out again? I know that *my* machine (a high-power PC) wouldn't be able
Of course we wouldn't want that. But, losing a few seconds of audio is a
bit different than losing an important change to the layout of the world
because the browser that originated the change never finished sending it
out. Real-time audio doesn't change the world permanently, so if you lose
some audio information it isn't a big deal.
>No, when we start getting into this sort of high-bandwidth application,
>we *have* to abandon the traditional models wherein the server does
Distributed is definately the way to go. It's where the computer industry
itself seems to be heading these days as well (System 7 Personal File
Sharing, Windows for Workgroups, Personal Netware, etc.)
>all the hard work, and assume that our clients are at least moderately
>capable. The server acts as the "memory" for the system, and co-ordinates;
>everything else *has* to be distributed to the clients, and multiplexed
>around. Otherwise, you're gonna see bottlenecks like nothing you've
>ever seen before...
We could let the clients register updates with the server first and then
with all the clients, thus providing a backup for the other clients to use
in resynchronizing themselves in the event of failure. The trick is making
sure the clients can detect this scenario and fix the problem with little
or no intervention. It's not impossible, it just requires careful thinking
of all the possibilities.
As I stated in a previous post, the only real problem I see with
implementing behaviors on the browser side is how to create objects that
still "exist" (in a virtual sort of way) when they're not being browsed.
There should at least be hooks into the servers to allow the scene to be
manipulated locally and have the changes sent to the browsers. For heavily
visited sites or sites with low processing power and/or bandwidth, you
simply don't use this feature. But if I want to run a small private
simulation for friends on my local machine, I would want this ability.
[ Yep we're getting off topic. We really need another mailing list where
those of us interested in this matter can discuss it in parallel with the
main VRML discussion. ]
-- invid@msen.com In the end, there can be only one. http://www.msen.com/~invid - Ramirez, "Highlander"