Yes. So? I've been assuming that a VRMUD browser/client will need this
level of intelligence; one of the main jobs of the server will be to
co-ordinate the browsers.
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
to handle that, nor anything I'm likely to have in the next few years
-- you're talking a *colossal* amount of traffic. (And mind, that's
only for one room; now multiply that out by the number of rooms that
the server is supposed to be managing.) No one is going to start
dedicating Crays (or big networks of Reality Engines) to running MUDs
(probably), so where are we going to get the cycles?
No, when we start getting into this sort of high-bandwidth application,
we *have* to abandon the traditional models wherein the server does
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...
-- Justin
Who knows we're getting off-topic again,
but doesn't know the right place to
redirect this one. We may well want a
VRMUD list sometime soon, I suspect...
Random Quote du Jour:
"Newsgroups, on the other hand, are on-going discussions with no deadlines,
no editing, and often no content."
-- Evelyn Leeper