2.1.1. Objects

Although modern physics tells us that everything is composed of atoms, most of us do not have to consider this nanoscopic view in our daily lives. If I look at the cup sitting beside me, I do not see metal ions and plastic polymers: I see a cup. Rather than seeing billions of individual atoms, our intuitive perception is that of a single thing. Why mention this? As we think about virtual reality, it is important to keep in mind that the ultimate purpose is to simulate reality only insofar as it creates a more convincing illusion for the user's perceptions. Considering what aspects of the virtual environment are most important to the perceptions of the user reduces the problem from the impossible proposition of simulating literally everything to simulating only those aspects of reality which are most important.

Perhaps the most important psychological abstraction that people apply to the surrounding physical world is that of the dividing things into individual "objects". One definition for the term "object" could be a material thing which is somehow physically distinct from its surroundings. This definition is deliberately broad, as the crucial distictions are a matter of perception. Consider the way two people might perceive a particular piece of clothing: a jacket. A tailor would see the jacket as many parts: buttons, sleeves, pockets, lining and so forth, each a physically distinct object. However, to a man who runs a clothing store the jacket is a unit, an item to be sold at a certain price. He considers the jacket to be a single object; his inventory does not list that there are thirty buttons, twenty sleeves, and twenty pockets, the inventory simply lists that there are ten jackets. Virtual reality must be designed to best reflect our psychological models of the world.

Object-Oriented Programming (OOP) is a widely used technique for writing programs that incorporates some of our intuitive conception of objects. Specifically, objects are defined by the ways they are used and their internal (data) structure. Objects are grouped by their physical relationships (one object contains another) and conceptual relationships (one object performs similar tasks as another.) An important aspect of OOP which we will return to later is that in a pure object-oriented system all actions happen as interactions between objects: one object using another to perform some task.

2.1.2. Networks

A single computer is built from many interacting components. The central processing unit, acting under the instruction of the software, communicates with the various components of the system to cause secondary processing or other desired effects (such as displaying something on screen). Normally the system components must be directly wired to the computer. The breakthrough created by computer networks was the ability to expand communication between computing devices from the area around the computer where wires could physically reach to anywhere in the world that messages could be routed to. A message (called a packet) bears information about where it is from and where it wants to go, and is passed from system to system until it reaches its destination. Each hop from one computer to another may involve a different transmission medium --- copper wire, fiber optics, radio, carrier pigeon, etc. This is the basis for the Internet.

To allow users all over the world to collaborate in a shared virtual world, Virtual Reality must be designed from the ground up with the features and limitations of modern networks in mind. One aspect of the Internet is the level of abstraction presented to the user. The most common protocol for most applications is Transmission Control Protocol (TCP), which allows the user to establish a bidirectional connection to transfer in-order byte streams between two systems. It is up to the programmer to make sense of this information. To express the ideas of object-oriented programming described previously, another layer of abstraction needs to be built: one which makes it possible to access and describe objects independently of their location on the network. This is the purpose of the VOS core.

2.1.3. Additional Concepts

For the remainder of this manual, is it presumed that you are familiar with the common terminology and jargon related to networks and object oriented programming. Some background in three dimensional graphics will also be necessary when we discuss the VOS virtual reality extensions in a later chapter in this manual. This chapter describes the abstractions provided by the VOS core, which is generic and not specific to representing 3D data, however some examples of VOS in use may describe basic manipulation of 3D objects. This section describes some terms and concepts useful later in discussing VOS.

Although their meaning should be fairly intuitive, before getting into any serious discussion of network terminology two terms need to be clarified. Something is local if, from the perspective of the current program or user, it is located on the same machine within the same process or address space. Accessing the local resource requires no interaction with any network transport, including loopback sockets. Something is remote if accessing the resource requires going over some sort of network transport to get to it --- in other words, anything that is not local is considered remote.

Network transparent (or "X can be done transparently") means that the interface presented to the user allows him or her to do some operation without having to be aware (or at least only minimally aware) that some interaction over the network may need to take place.

The first important concept is that of the Remote Procedure Call (RPC). Normally when when a local procedure is called, control is transfered to the routine it executes and when done control is returned to the caller. In an RPC setting, we want to transparently execute a procedure on a remote host without changing the programming interface. This is acomplished by implementing the procedure locally as a stub. The purpose of a stub is to take the parameters passed to the procedure call, create a network message with those parameters, send the message requesting the action to the remote host, and wait for a reply. When it gets the reply, control is finally returned to the calling process. RPC is fairly simple, but has drawbacks. The most significant is simply that it is a poor fit with modern object-oriented programming, lacking any notion of objects but only of basic data types.

In between RPC and full Object-Oriented systems are so-called Message Passing Systems. These systems provide abstract nodes which can exchange messages, but may be arbitrary spread over the actual network. This makes distributed processing more adaptable than RPC systems, but does not have all the trappings of a full object-oriented solution.

Finally there are Distributed Object Systems, sometimes also referred to as Object Brokering[1] systems, which fundamentally extend the notion of RPC to support object-oriented programming. The basic idea of using stubs to stand in and generate requests is the same, but now rather than simple procedure calls we are invoking methods on specific objects that exist somewhere on the network. The design of VOS is based on this idea with a strong nod towards the flexibility provided by pure message passing.

2.1.4. VOS Terminology

This section briefly describes some VOS-specific jargon you will want to be familiar with before finally plunging into the full discussion of the VOS design in the next section.

The most important term is Virtual Object or Vobject (capitalization of the V is optional). Because the term "object" is extremely broad in the English language as well as having a variety of technical meanings, we use the term "Vobject" to unambiguously refer to the abstraction provided by VOS. Vobjects are formally defined in the next section, but one important detail to note is that in object-oriented terms Vobjects are instances, not classes.

Vobjects are distinguished by their set of types. Unlike the formal class hierarchies found in most OOP languages, vobject type string have minimal inheritance rules and can be used to express nearly any important detail about how an application should go about treating this vobject. Types are most frequently used to express the interface or structure of a vobject, and are defined using VOS Object Type Definitions (OTD).

Vobjects interconnect with one another with bidirectional, oriented links. A Vobject is aware of both incoming links, termed parents and outgoing links, termed children. If the use of these terms seem strange, note that the most common structure for Vobjects to take are hierarchical tree structures. These terms come from genealogy, by analogy with biology, via computer science and graph theory. The vobject pointed to by the head of the link is a child of the vobject at the tail of the link; likewise the vobject at the tail of the link is the parent of the vobject at the head of the link. Figure 2-2 should help clarify this.

Notification Subscription, also known as the "view" part of the Model-View-Controller (MVC) pattern, is termed listening in VOS. This is a general programming technique of enabling code to register interest in a particular resource in a seperate part of the program. When that resource changes state, all listeners are automatically notified. This obviates the need to periodically poll the resource to see if anything has changed.

A single program will usually create and host a number of local vobjects. These vobjects must have some way of communicating over the network. In particular, it is desirable to multiplex access to these vobjects over a single socket. This is acomplished by binding normal vobjects to a special vobject called a site. A site acts as a bridge between local and remote vobjects by exchanging VOS messages over the desired network channel. The handshaking process when two sites first connect is called site peering.