Subject: Re: Yawn, VROOMs etc.

From: Andrew Wilson <[email-masked]>
Date: Thu, 20 Aug 1992 05:49:35 -0700

Hi,

	I've been speaking to Johan Andersson ([email-masked]), who's
the coordinator of software design for the CDLib project at Genesis.
Genesis is LPmuds version of LambdaMOO, it's the original LP site, and CDlib
is LPmud's 'LambdaCore'.  Johan tells me that Genesis can ALREADY send
and receive udp packages (data packets) by making calls to SERVER functions.
i.e. LPmuds have built-ins that can do what my network object can do.  This
means that they're probably a couple of orders of magnitude FASTER than my
MOO code could ever be.  I'm not saying that Johan's work is identical to what
we've been able to acieve with MOO-net BUT it bears enough similarities to make
me think that the time when we will able to network MOOs AND LPmuds together
is not far away.
	They even have the beginnings of a theory about VROOMs!

I'd like to know what you think, seriously, about turning MOO-net into M**-net.

Thanks,
	Andrew Wilson - Networker @ LambdaMOO + DreaMOO + ChaosMOO

ps.	In case it wasn't clear, VROOMs have been installed on the above 3 MOO
	sites.  Drop in sometime if you wan't to learn more about them.  A.

---

From: Andrew Wilson <[email-masked]>
Date: Thu, 20 Aug 1992 06:38:22 -0700

Hi,
	Ryan Daum ([email-masked]) just e-mailed me and I think
you'd all like to hear this.  I said:

> pps.	Is this the sort of thing you want to see in LambdaCore?

And Ryan replied:

>  Well, to tell you the truth, I'd rather see VPLAYERS than VROOMS.  I mean,
>not actually creating a remote player object, but instead "faking" it by
>keeping a database of temporary objects which act like players (perhaps even
>children of $player) but simply have a :tell which sends to the player and
>allow the player to issue commands through an event system of some sort.

>   This is still sketchy in my mind, though.  I wouldn't advocate actually
>letting the player assume a connection on the other MOO.  I'd rather see the
>player given a sort of view "into the world" and some special feature objects
>which let them work in the remote rooms (with In-DB parsing one could
>manipulate objects on the other machine qurtie well, as well)

My reply:

Mmm, I don't quite follow you there.  I'll admit that I've used rather
confusing terminology in the past;  VPLAYERs forinstance, don't exist in
any recognisable for in my networking system.  I was a little confused
when I first mentioned them, and now they refuse to go away!  I DO use
MOO $player objects to maintain the connections between MOOs.  CardiffMOO
on LambdaMOO is a player who does nothing but recieve data-packets from my
MOO in Cardiff, which he then distributes to the network object that 
Networker carries around.
	If I understand you correctly, then YOUR idea of a VPLAYER is rather
like a LambdaMOO puppet, something which can act as the eyes and ears of a 
player on another MOO.  This is CERTAINLY possible, even with the bug-infested
networking system we have at the moment.  And a VPLAYER with no greater
functionality than a LambdaMOO puppet could be designed to operate with
the network.  Good idea.
	As for manipulating objects on other sites, well it is not a trivial
problem.  As you'll soon become aware, the LPmud systems are evolving
something which looks very like MOO-net and I think that it would be 
a good idea to design ways and means of interacting with remote objects
which are not specific to the representation of those objects on the
remote sites to which our M** connects.  In the short term you could certainly
have MOO specific mechanisms.  We could ask your VPLAYERs to 'get ball'
or to ': goes to sleep in the corner.', and your VPLAYERs, @kids of $player,
would do what you asked.  However, what I have in mind is a distributed-object
protocol (A Whaaat?!), by which I mean a global object schema which all
networked sites, MOOs and LPmuds, would agree to use in the design of objects
that they wanted to be available across the network.
	For example, the documents in the LambdaHouse library would be @kids of
$generic-distributed-document and could be read by anyone on an LPmud who was
in the same VROOM.  By adopting a $generic-distributed-<whatever> approach
we, on the MOOs could ensure that only $genric-distributed-<whatever>s
could be accessed by other sites.  This is good for security reasons and means
that all networked sites can SHARE the developement cost (time, memory-space)
of new objects.
	So we have VROOMs to limit the access of other M**s to rooms on our
site, and $genric-distributed-<whatever>s to limit the effect that other M**s
can have on our objects.

Comments?
Donations?
Sympathy?

Andrew Wilson - Networker @ here, there and soon everywhere.