Subject: Inter-MOO communication II

From: Andrew Wilson <[email-masked]>
Date: Mon, 3 Aug 1992 08:43:15 -0700

Hi,
	I sent this one to Amy when it should really have gone to
everyone:

---

Hi Amy,

	you say:

>How about making each VROOM a tv studio.  In the studio,
>ou can watch what other MOOStudios are doing, one at a time,
>by flipping channels.  An "ON THE AIR" light indicates
>whether any other MOO is watching your studio.

	A TV Studio eh?  Mmm, well, cool I suppose, but I think that
the amount of programming involved would be greater than for a simple VROOM.
The main problem that I see with VROOMs is the possibility of their being
simply too many people all talking at the same time.  From experience
of places like LambdaMOO I'd say that a VROOM would be unworkable if there
were more than say five people talking at the same time.  This isn't a problem
with VROOMs specifically, the same thing happens now whenever 3 or more chatty
people meet in a room.  It's just that VROOMs by their nature would tend to
have more people in them than normal.  Conventional chat sites get round this
problem by having more than one room for people to go to, so they have somewhere
to go if they DO want a quiet conversation or for reasons of privacy.
	Of course there's nothing to stop you implementing a group of
connected VROOMS.  It's just a matter of each participating MOO having a
topologically (sp?) equivalent area consisting of $rooms which implement
the VROOM code.  If Frederique on GodNet goes north from the first VROOM
she'll move into the second VROOM and, provided that LambdaMOO's got the 
same (V)topology then BigMac will be able to join her again by simply
going north from his own 'first' VROOM on LambdaMOO.
	There is a problem with my idea for implementing VROOMs which
would tend to limit the extent of the Vtopology, that is, that each room
that implements the VROOM code would be linked to it's partners by a network
connection implemented as a VPLAYER.  So for example, if there were 5
participating MOOs, including LambdaMOO as the 'central' VROOM then this
would require 8 connections: 2 for each of the 'outside' MOO sites and 8
for poor old LambdaMOO.  If you add another VROOM to the Vtopology then
this doubles the number of connections required!  Obviously this is a MAJOR
shortcoming in my design.  I think that VROOMs, if their implementation
remains unaltered, will make Vtopologies of more than say 3 VROOMs completely
unworkable.

DOING IT DIFFERENTLY 
	There IS another 'more difficult' implementation strategy which
will reduce the number of connections required dramatically.  Each participating
MOO connects to LambdaMOOs central VROOM using a single connection and
LambdaMOO connects out to the other MOOs.  With 5 sites this means 8 connections
as before.  However, outlying rooms are coded differently, anything 'said'
in an outlying room is caught (by the room's tell verb, or whatever) and
passed to the VPLAYER connections in the central VROOM, together with a 'tag'
indicating its destination in terms of the Vtopology.  The information
is passed to each of the outlying MOO sites and the tag is decoded to 'echo'
the information in the correct VROOM on each site.

	A VROOM is also meant to 'look' like any other room in the MOO so
ideally a simple 'look' would display the contents of the VROOM by deriving
them from the contents of the connected rooms on all the participating
sites.  There IS a significant problem with net-lag to be overcome, and in
addition to this we also need a sensible way of ensuring that we don't
confuse the results of one request for 'look' information to other sites with
results from some other different request.  I'm beginning to get out of my
depth here algorithm-wise but I'll keep at it until someone shouts 'fraud'
or shows me how to do it.

	I think that the room analogy that exists on every MUD in the world
is wonderfully simple and really very efficient, from the user's point of view.
If I was going to seek to complicate the coding of VROOMs then I'd try
to do it at the 'hidden' level described above in 'DOING IT DIFFERENTLY' and
seek my efficiency there rather than present users with another analogy.

There are probably much better ways to do this, I'm just trying to do it with
what little resources we have at hand.

Andrew Wilson.

ps.  Of course you realise that all of the above is simply your MOOStudio
idea with different words.  But I HAD to write all this just to be sure.
A. :-)

---

I never could get the hang of this new-fangled teknollogee stuff anyway!

Andrew.