Creating Interreality: The Virtual Object System: Version 0.12.0
Prev	Chapter 2. Concepts and Design	Next

2.2. The VOS Design

2.2.1. Goals

The purpose of the VOS core is to support the following features:

abstract object-oriented message passing
methods for naming, addressing and interconnecting vobjects
ability to add listeners to all aspects of vobjects
uniform naming system, based on URLs
polymorphic object typing and extension system

2.2.2. The Vobject Model

The basic unit of VOS are Vobjects, which are formally defined by the following object model:

The Vobject exists with a unique name as a direct child of exactly one site.
The Vobject can be a source and destination for exchanging messages with other vobjects, with sites handling intermediate transport as necessary.
The Vobject has a set of type strings. These may be used to describe what interfaces this vobject supports, how to interpret the meaning of child vobjects, or tag the vobject for other special treatment by an application.
The Vobject has an ordered, associative list of links to other Vobjects. Each link has a position and is tagged with an additional contextual name. This used by the application to determine how to interpret the child (linked-to vobject) in the context of the parent (linked-from vobject). The contextual name may be used more than once in a given child list, and may be blank, in which case the link is characterized only by its position.
Vobject parent-child links are bidirectional. A Vobject can be a child of multiple other vobjects, and should be aware of each inbound link. The application can get a list of all parents of a particular Vobject. In the case that one side does not honor this link, the parent (vobject on which the link is outgoing) is definitive.

Figure 2-3. An example site with six vobjects describing an simple virtual world

Sites are a special type of Vobject which, in addition to following the above object model, act as the connection point between vobjects which are not in the same address space. Sites encapsulate some networking medium used to transport messages to their destination; this medium could be TCP/IP, ATM Virtual Circuts, shared memory backplanes or whatever other systems one might run VOS over.[1]

As will be discussed below, a vobject may be refered to through many possible paths, making it difficult to determine if two given paths actually refer to the same vobject. Because of this, every vobject is required to be bound to exactly one site as a direct child with a unique contextual name. With this restriction it becomes possible to give objects short unique names and one should need only the site contact information and vobject's site contextual name to address a given vobject.

2.2.4. Messages

A message consists of the following information.

A message type, may be one of: message, update, messageblock, default, include (the latter three are special script processing directives)
To and From fields: names of the source and destination vobjects
A Method field: indicates the request or purpose of this message
A Nonce field: used to match replies with requests; should be otherwise unique
A Dependency field: the receiving site should defer delivery of this message until it has sent out messages bearing the nonces listed in this field (see the section on scripting below.)
A Time field: the receiving site should defer delivery for this many seconds once its dependencies are satisfied.
After the above header fields there is an ordered, associative list of parameters. Each parameter has a key (which may not be blank but may be repeated in the same message) and a value.

Items 1-6 are headers containing message metainformation that must be treated specially, item 7 is the message "payload", which is split into user-defined fields. Substitution is done on the values of items 2-7 (see the section on substitution below.)

Messages with the update type are a special sort. These messages indicate that a requested or listened-to bit of information has changed. It is desirable to direct these cache updates to the code handling that particular remote vobject. As a result, an "update" type messages suggests that the message be delivered to the local stub for the remote object, which contains the the code for handling request replies and cache updates.

If any of the To, From or Method fields are missing, the default is used. These default fields are specific to each individual connection between two sites as part of the session state. The initial value of these defaults are the remote site as "To", the local site as "From", and blank for "Method". This means that a message bearing only a method and a payload is legal, as the "From" and "To" fields are implicitly the sending and receiving sites respectively. The default is changed using a message of type "default", from which the to, from and method headers will be used for the new defaults.

2.2.5. Types

The core of the VOS extension mechanism is the extremely flexible vobject type system. Each Vobject has a set of type strings, and the elements of this set are used to advise the application on how to handle this Vobject. This may include what messages the Vobject accepts or produces, the names, types and interpretation of expected child objects, or other domain-specific metainformation about the vobject. Vobjects may have any number of type strings. If no types are specified, the object only supports the basic vobject linking API.

Type strings are almost free form, with only one notable exception. If a type contains one or more period characters ('.', ASCII 46), it means that the type is a subclass of each type string that would be produced if the portion of the type string following each period were removed in turn. For example, a vobject with the type "object3d.cylinder" inherits all the aspects of "object3d". Were there to be another subclass "object3d.cylinder.foo" (not a real type) it would be expected to inherit all aspects from "object3d" as well as "object3d.cylinder". A corollary from this is that if an application encounters a type it does not understand (such as the example "object3d.cylinder.foo") it may work its way up the inheritance until it finds a type that it does understand (perhaps "object3d.cylinder" in this case.)

2.2.6. Linking and Naming

Although one of the main uses of vobject links are to to group vobjects in "contains" or "describes" relationships which typically forms trees or DAGs (Directed Acyclic Graphs). vobject links can form any directed graph. A vobject has an ordered, associative list of its outgoing links as well as a list of the links coming in.

Links can actually be thought of data structures in their own right. They list the parent (source) and child (destination) vobjects, as well as the contextual name and position in the parent's child list. Each link in the child list is characterized by its position; the name (which may be repeated or blank) is used to determine the context in which to interpret the particular child vobject. For example, in figure 2-3 the vobject with site name 94273048 has four child links. These links are named "position", "orientation", "scaling" and "material". Each linked-to vobject has the "property" type, which means they store some blob of data. Because the parent vobject is of type "object3d", the information stored in the vobject linked through to the "orientation" link is used by the application to affect the presentation of the vobject, in this case by changing its rotation.

Vobjects are addressed using URLs in the format

vop://hostname[:port]/objname

Consider the following examples, all of which ultimately refer to the same vobject .

vop://interreality.org/world/ball/position

This refers to the vobject storing the position of a ball, which is contained in a virtual world at the site interreality.org. Note that this path is not the only way of referring to this object. Here are a couple more ways:

vop://interreality.org/1264095060
vop://interreality.org/1474612399/position

The former is the unique name of the Vobject on its site. The latter directly addresses the "position" object via the "ball" Vobject, instead of indirecting through the "world" Vobject first.

Note that the fact that "vop://interreality.org/1264095060" happens to denote the position of some thing is entirely contextual, and determined by the parent-child linking. Another Vobject could easily link to this with a different name, in which case the same vobject could take on an entirely different meaning --- because a single vobject may have multiple types such a situation is quite reasonable.

Because the basic Vobject linking model is standard across all vobjects, the same tools to access and inspect the Vobject structure can be used for a variety of applications. For example, one tool is the command line shell mesh (described in chapter 3) which allows one to browse vobject structures using familiar commands like "cd" and "ls" as well as send and receive messages interactively.

If the port is omitted, the default port 4231 is assumed.

2.2.7. Listeners

Vobjects essentially consist of three pieces of data: the children list, the parent set, and the type set. Listeners enable the programmer to request that a particular vobject send a notification update message whenever some state changes. The notifications are: child add/replace/remove, parent add/remove and type add/remove. The concept of listeners is also used for some object types as well (most notably the "property" type.)

2.2.8. Substitution and Scripting

Not yet written, but chapter 6 (the protocol documentation) has some information. At any rate, this is an advanced topic that that you don't need to be aware of at all to understand ond use the C++ API.