[MUD-Dev] Languages for MUD drivers

Laurent Bossavit bossavit at cybercable.fr
Sat Nov 20 01:22:22 New Zealand Daylight Time 1999

JClaw wrote :

> There are two major limitations in COOLMUD:
> 1)  Inheritance may not span MUDs.
> 2)  To program an object, both the player and the object being
>     programmed must reside on the same server.

Interesting. I ended up having to implement the same restrictions in 
my distributed extension to MOO - and from that experience I have a 
suspicion that the stated reason for these limitations (reducing 
network traffic) covers deeper, conceptual issues.

> Object migration between hosts is not a trivial problem, but it is
> also a problem that is well known and has significant prior art.

For extensive documentation recursively follow links starting out 

> - There is no innate difference between a local object and a remote
> object other than responsiveness. 

This is tricky - that word 'responsiveness' hides some assumptions; 
e.g. that remote calls eventually return. In fact, network 
connections are known to get broken from time to time; we must assume 
that remote calls may fail, hence that all calls may fail. There is 
also the problem of 'trusting' remote servers. Remote calls need to 
be made securely, otherwise they could be exploited. Hence you need a 
universal security model. The E language has interesting ways to deal 
with both issues.

> You must be able to rewrite an object's behaviour without changing
> the source for that object. 

Please expand ?

> Very Yo-like.

Perhaps not surprising, given that Stephen White and I both came from 
the same place - MOO - with the same problem - add distributed 
capabilities. I don't claim the same success. :)

Do androids dream of electronic sheep ?

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list