The Server View of the Context-User-Item Model
The presences of C-U-I objects on the Context Server are authoritative with respect to the shared state of those objects. In other words, when there are questions about the true state of reality, what the server says rules. A client is authoritative only with respect two kinds of things: the user interface interpretation of those objects as presented to its own user, and the representation of the user's intentions to the server.
Furthermore, since a client in some context only communicates with the server for that context, the client only has to worry about managing a communications relationship with one other party. The context's Context Server, in contrast, communicates with all the clients in that context, hence its model of the world is necessarily somewhat more complicated.
The persistent states of C-U-I objects are maintained by the server in its object database. In the current implementation, these are stored as JSON object descriptors. When there are no users in a context, the context sits in a quiescent state in the object database. A quiescent context is only activated when a user enters it. When the context is activated, the server loads its representation from the object database, instantiates a live context object for it, and then manages client interaction with it. When the last client leaves the context, its persistent state is checkpointed back to the object database (though certain operations in a live context can also trigger such checkpointing during normal operation) and the context again becomes quiescent. Actually, it is possible, if application requirements make it necessary, for a context to be made active absent any users within it, or to be kept active after all users have left, but this is not the normal mode of operation.
When a context is activated, not only is the context object loaded from the database, but so are any items that the context contains. Furthermore, users themselves (and the items the contain) may have persistent representations that are also loaded upon entry.
An object's descriptor in the database includes descriptors for any mods that may be attached to that object. Developing an application consists of defining the context, its mods, its items, and its items' mods. A context or item may also define what we call user mods, which are temporary mods that are attached to a user or to one of the user's items when the user enters the context, then discarded again when the user leaves.
The Context Server provides a standard library of mods that can be recombined in different ways to produce different applications. In addition, it is possible to program new server-side mod classes using a standard Java API. As long as the mod classes are loadable from the server's configured class path, they may be used just like any of the built in mods. (In the fullness of time we hope to enable server mods to be implemented in Javascript, so that application developers can develop both the client and server portions of their applications in a common language framework. This will be coupled with a modular packaging scheme enabling developers to generate a single deployment package for an application that can be uploaded to the server and installed.)
When a server creates a new context, by convention it assigns it a ref of
the form "context.uniq_id", where
uniq is unique token generated at server startup time, so
that multipe servers sharing a common object database can generate unique
identifiers without collisions, and id is a sequential integer
number that increments with each context created. It is not required that
manually created contexts follow this convention, though it is useful for
documentary purposes to follow a similar convention by identifying contexts
with refs of the form "context.tag", where
tag is a mnemonic string of some kind. Similary, items are
given refs of the form "item.uniq_id" and users are
given refs of the form "user.uniq_id".
Clones, when they are created, are assigned refs by suffixing
".cloneid" to the base ref of the master object from which
they are cloned, where cloneid is a unique number issued by
the server. Note however, that while a non-clone object's ref is a permanent
attribute of that object, clone refs are as ephemeral as the clone objects they
refer to.
The Context Object
Contexts are stored in the object database indexed by their reference strings. A context is described by a JSON descriptor of the form:
{
type:"context",
name:STR,
capacity:INT,
baseCapacity:?INT,
semiprivate:?BOOL,
restricted:?BOOL,
mods:[MODDESC],
usermods:[MODDESC],
contents:[ITEMREF_STR]
}
where:
nameis the context's printable name, which may be significant in the application user interface.capacityis the maximum number of users permitted in the context at any one time. A value of -1 indicates that this is unlimited.baseCapacity, if given, establishes the capacity of the context above which additional users attempting entry will trigger the creation of a clone. [Note: the context cloning feature is not yet fully implemented.]semiprivateis a flag that, if given and true, indicates that this is what we call a semi-private context. In a semi-private context, users are not informed of the presence of other users and may not interact with them directly.restrictedis a flag that, if given and true, indicates that entry to the context is access controlled. A user attempting to enter a restricted context may only do so if they are carrying the proper entry key. This is explained in greater detail in the section on the ContextKey mod.mods, if present, is an array of mods attached to the context. Each of these is a JSON object describing a particular mod. The form of these mod descriptors varies depending on what kind of mods they are. The current set of supported mods is described here.usermods, if present, is an array of mods that should be attached to users who enter the context. As with the context's own mods, the form of these varies depending on mod type. See the mod documentation for details.contents, if present, is an array of item refs. When the context is loaded from the object database, these items will also be loaded and inserted into the context's contents collection.
The Item Object
Items are stored in the object database indexed by their reference strings. An item is described by a JSON descriptor of the form:
{
type:"item",
name:STR,
mods:[MODDESC],
contents:[ITEMREF_STR],
cont:?BOOL,
deletable:?BOOL
}
where:
nameis the item's printable name.mods, if present, is an array of mods attached to the item. Each of these is a JSON object describing a particular mod. The form of these mod descriptors varies depending on what kind of mods they are. The current set of supported mods is described here.contents, if present, is an array of item refs. When the item is loaded from the object database, these items will also be loaded and inserted into the item's contents collection.contis a flag that, if present and true, indicates that the item may be used as a container (i.e., it may contain other items, even if it does not currently do so).deletableis a flag that, if present and true, indicates that the item may be deleted by ordinary users by sending it a"delete"message.
The User Object
Users are stored in the object database indexed by their reference strings. An user is described by a JSON descriptor of the form:
{
type:"user",
name:STR,
mods:[MODDESC],
contents:[ITEMREF_STR]
}
where:
nameis the user's printable name.mods, if present, is an array of mods attached to the user. Each of these is a JSON object describing a particular mod. The form of these mod descriptors varies depending on what kind of mods they are. The current set of supported mods is described here.contents, if present, is an array of item refs. When the user is loaded from the object database, these items will also be loaded and inserted into the user's contents collection.