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

   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 */
	    raise E_PERM;	/* permission denied */