Please note:The terms parameter and property are both used in reference to objects to refer to state variables that an object contains to maintain its state.

Server Object Hierarchy

The server on which the Virtual Cell system is implemented on is a LambaMOO server running a modified version of the standard core database. A new object hierarchy of

Like the case of object hierarchies in Smalltalk, the LambdaMOO server only supports single inheritence, so it is quite common for the object hierarchy to bend during development.

Generic Thing

#283 defines the following functionality
set(property,new_value)
Attempt to change property's value to new_value. This may have side effects depending on the object. Interested objects are notified of the change in value, including the caller.
update(property,new_value)
Change the property's value to new_value. Unlike set, the appropriate side effects are normally considered to have already occurred. Interested objects other than the calling object are notified of the change. Update is intended for circumstances such as player movement, when atleast one machine connected to the server maintains that the new value is correct. Another use for update is for objects whose VRML representation contains user interface elements that result in discrete values.
get(property)
Returns the value of property for this object.
add_interest(interested_object)
interested_object is added to the set of objects receiving updates about this object.
remove_interest(interested_object)
interested_object is removed from the set of objects receiving updates about this object.
get_representation(format)
Returns the parameter list appropriate for a given format to describe this object. Currently the only used format is VRML.

Much of this functionality exists to support possible future research. For example, an editing client providing a Smalltalk like Browser would require a different representation format than the current VRML client. Likewise, multiple servers could be networked together for the purposes of distributing a complex simulation.

If the need arises, the event listener model may be modified to support automatically ignoring unimportant events, although this has not been the case so far.

Generic Server

One of the features the VCell database is designed to support is distributed processing. Due to the nature of the LambdaMOO server, each active network connection eventually associates with an object in the database in a one to one manner. Like Generic Player, most of the functionality in this object will be to assist the foreign server in carrying out its tasks.

Generic Player

While players are conceptually a type of server, the fact that players are normally tied into an interactive object makes them a type of Generic Thing. Most of the functionality built into the Generic Player class is intended for implementing tasks such as getting an object's local representation and expressing interest to receive updates. For example, the client calls get_representation_of on the player's object, and the server's implementation of this function automatically adds the player to the update lists for the appropriate object.

Specific Functionality

Since the primary concern for the server is communication with a client displaying VRML representations of an interactive world, certain specific functionality was required. This section attempts to explain what interesting functionality was required.

Properties and Contortions

Location

On the LambdaMOO server, two properties location and contents are maintained for each object. Naturally, if object A contains object B, A's location is object B, and A is in the list of B's contents. Because of this duality, objects are moved by setting their location, and the contents field is updated as a side effect. Since sending updates on the entire contents list would be possibly expensive, updates are sent instead on two special properties add_contents and remove_contents as needed.

Position, Orientation, and Scale

To maintain correct client side representation, the numeric values for each of these properties are converted to floating point numbers. This is largely for the sanity of programmers, since the LambdaMOO server refuses to automatically convert between the two.

Properties Important to the Client

Any object which will get displayed by the client is required to have the following basic properties
Class
A string representing the subclass of Thing to use for the object.
Name
A string representing the object's name.
Position
The X, Y, and Z coordinates of the object. This is expressed as a list of floating point numbers.
Orientation
The X, Y, Z, and Theta orientation of the object. This is expected to conform to the VRML standards for orientation vector and angle, represented as a list of floating point numbers.
Scale
A floating point number which is used to scale the objects VRML representation on all three axes.
Location
A reference to the object containing this object
Contents
A list of the object contained in this object. The objects are specified by object references.
An object may have more parameters than these, in which case they will be initially presented to the client as a list of parameter names and values.

The parameters for an object are fetched by calling the get_representation verb, which returns a list of the parameter values. The first seven parameters are expected to be in the order listed above.

Server Side Programming

One of the benefits of the listener model is that intelligent (or atleast interesting) responsive behaviors are easier to implement. More importantly, objects which have no interesting behavior do not add overhead when placed in the vicinity of useful objects.

One of the current problems involved the fact that all events are being processed in a sequential manner. If the events can be divided into two classes, absolute and relative changes, then it would become possible to handle event streams which are occuring faster than processing can satisfy. Two difficulties arise: 1. Each event has to be classified, and this must be know to the event queuing mechanisms on both the client and the server. 2. The client side stubs have to be extended to handle this data.