[MUD-Dev] Languages for MUD drivers
Laurent Bossavit
bossavit at cybercable.fr
Sat Nov 20 01:22:22 CET 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
here:
http://www.luca.demon.co.uk/Ambit/Ambit.html
> - 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. :)
-[Morendil]-
Do androids dream of electronic sheep ?
_______________________________________________
MUD-Dev maillist - MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list