[MUD-Dev] Languages for MUD drivers

[Laurent Bossavit]

Ian Macintosh sez:

> Distributed processing support can be handled by running multiple
> processes and interconnecting them.  I've always thought that this is
> a better way of handling large systems and a large number of users.
> ie, segment areas (zones) onto different servers and link them.

There's no really good (read transparent) way to interconnect several 
MOO servers in that way. Suppose I'm running the Feral Forest on 
server A, the Damp Dungeon on server B; I want the key from the lower 
dungeon cell to open the witch's hut in the forest - hence I want the 
player to be able to take the key and move from A to B, moving the 
key with em - and there's no way AFAIK that can be done with MOO.

Even assuming something like an 'object exchange protocol' that would 
let server A open a connection to server B, spit out the key object's 
code and properties so that a new, equivalent object can be created 
there, and the old key deleted; assuming I have a way to make sure 
the key won't be duplicated or deleted altogether if something 
happens to the network connection between A and B while this is going 
on; assuming I can do the same to the player object; assuming I can 
require the player emself to disconnect from A and reconnect to B in 
an orderly fashion whenever this happens - which implies a custom 
client program, or tech support headaches...

Hmm, I can't assume all of the above anyway since it's far from 
realistic, but you see where this would lead - a lot of in-DB code 
that deals only with such interconnections. (And what if the key has 
a property pointing to another object local to A; and what if the key 
has parent objects that are not in B, etc. etc.) It's much better if 
such distributed processing is in some appropriate fashion a 
capability of the server itself. MOO as it is doesn't fit the bill; 
and adding these capabilities to a MOO server wouldn't be a piece of 
cake.

In fact, my port to Java did include distributed operation support, 
based on RMI. One of the first things that became apparent as I was 
implementing it was that some MOO-language modifications would be 
necessary; the very least I could get away with was a syntactic 
representation of remote objects, i.e. the literal
  #1
referred to the local #1 whereas
  #my.server.com:1
referred to #1 on my.server.com. With these modifications it was 
possible to call verbs and read or write properties on remote objects 
transparently, as if they were local.

But I soon realized I had in fact opened a very nasty can of worms. I 
had to add code to the server to prohibit creation of local objects 
that were children of remote objects, otherwise I would have had to 
implement a distributed database as well - which was both beyond me 
and beyond my time budget. Another problem was the permissions 
system; how the Wizard on server A would be prevented from having 
wizard access for server B's objects, or if I decided to 'trust' 
wizard bits between servers, how to securely authenticate server 
connections.

To cut a long story short, I eventually gave up on "good" 
disitributed support and left it in a fairly primitive state - I had 
to ship product and it didn't look as if it would see much use.

> I'm not sure of what you are refering to when you say concurrent
> processing support?  I understand the term, but I don't understand
> the context re reactive worlds? 

I'm basically referring to support for preemptive (rather than MOO's 
collaborative) multitasking. Task scheduling seems to be a primary 
cause of lag in MOO servers - true multithreading means a server is 
more responsive; at least that's the theory.

> Perhaps you could also elaborate reflective capabilities?

Well, MOO's at least got that - in spades : I mean the ability (in 
verb code) to find out what verbs and properties are defined on an 
object, and possibly to modify those. This is a central feature, at 
least IMHO, of a modern M* server - because it lets you write in-DB 
editors. This may seem peripheral to some, but it's crucial to the 
notion of a virtual reality : the point of MUDs and MOOs was that 
they could be modified 'from the inside', which made them more like 
the real world - we don't 'step outside' the real world when we want 
to modify it, but modify it we do !


-[Morendil]-
We all live in a yellow subroutine.




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev