COOLMUD is distributed in a different way than other "distributed" systems such as UnterMUD. Instead of providing a method of sending objects from database to database, COOLMUD allows you to define a suite of messages which may be passed between objects. The YO protocol and the COOLMUD database define the suite of messages for a particular implementation. For example, symbolically, a typical exchange between objects might be: object A object B -------- -------- - what is your location? - my location is ... - move yourself to ... - ok Objects don't actually move from machine to machine; they simply update their location and contents fields to move around. The object remains on the server it was created on; its location field simply 'points' to the object representing its new location. This means that anything which may be done with a local object can be done with a remote object. Thus, you may program a fancy object on your local mud, carry it to a remote mud, and all the functionality comes along with it. There are two major limitations in COOLMUD: 1) Inheritance may not span MUDs. The parent of an object must reside on the same MUD as the child object. This is done to reduce network traffic to an acceptable level, and to simplify the message passing system. 2) To program an object, both the player and the object being programmed must reside on the same server. This also reduces net traffic, since the COOL code only has go across one link (that between a player and the local MUD). Speed and Net Bandwidth When objects on different servers are communicating, they might send an average of 10 UDP-encoded YO messages back and forth per user command. Given the current speed of long-haul networks, it is impractical to run the YO protocol between machines across those links. However, several COOLMUD's might be used on a local cluster of machines on the same Ethernet. COOLMUD can also be used as a standalone system similar to MOO, with the advantages of multi-threading, multiple inheritance and a more portable programming interface. Ensuring Distributability In the design of COOLMUD, every effort was made to ensure that any object (program) written for use on a local server would work on a remote server as well. One major design decision was that the only way to get or set data on an object is to send it a message. There is no other way to get an object to change its properties, or to determine its properties. For example, the expression: var a; a = #3@foomud.location stores the location of object #3 on server 'foomud' in local variable a. This actually calls a method in the destination object (See Message Passing). A byproduct of this approach is that there is no permissions system. Each object may determine who may set or get its properties, by programming its methods appropriately. For example, an object may not wish to divulge its description to any caller except one that owns the object: method desc if (caller in owners) /* if caller owns this object, */ return desc; /* give it the description */ else raise E_PERM; /* permission denied */ endif endmethod