A: Virtual Object System. Technically, VOS refers to the core object technology for expressing interlinked structures of network objects. However, the term is often used broadly to describe the entire project.
A: A contraction of "Internet" and "Reality". The goal of creating a virtual reality system for the Internet that genuinely useful. The notion that all parts of reality are closely interconnected, and that our software systems must reflect this principal. It's also a cool domain name.
A: The project was originally hatched in the spring of 1999 with significantly different goals and architecture than what we would eventually settle on. The architecture went through many revisions with a lengthy prototype phase beween fall of 1999 and fall of 2000 where many ideas were tested in a Java implementation. The modern C++ implementation, embodying a third major redesign, was begun in the spring of 2001.
A: In terms of manpower, the vast majority of the work has been done by Peter Amstutz and Reed Hedges. Other contributers should be credited in the AUTHORS files. In terms of code size, VOS in total (including all libraries and applications) consists of about 45,000 lines of C++.
A: Presently (version 0.11.0) we support GNU/Linux and Microsoft Windows. Macintosh OS X mostly works, but we have encountered bugs in the compiler(!) and so we are waiting for a new compiler version to be released. We are working hard to have strong cross-platform support and would be very greatful for any help.
A: The VOS networking infrastructure was developed to solve the problem of providing an extremely flexible networking basis on which to build a multiuser virtual reality system. Along the way we noticed that VOS might be useful for quite a lot of other applications as well. The first chapter has more information about this.
A: VRML is little more than a file format with no protocol for sharing online the objects in a world. VOS tackles the problem from a network-centric approach, rather than the graphic-centric approach of VRML. We do intend to write a VRML loader which would parse a VRML file and create equivilent VOS objects for the components of the VRML scene.
A: Joining and downloading a world, seeing other avatars move about, smooth extrapolated motion, talking to other avatars, grabbing and manipulating objects (changing their position/orientation/scaling), adding new objects to the world, hypercards linking other worlds or resources, helper applications, dynamics simulation (gravity, collision detection and response),
A: The original reason had a lot to do with the fact that I didn't really know CORBA; my impression of it was that it had a steep learning curve and was fairly inelegant. I've since spent time researching it, and haven't found anything to contradict these initial impressions.
A: VOP is a general purpose messaging protocol which is not strictly tied to the notion of RPC. CORBA is quite firmly rooted in the server/stub model where skeletons are built based on interfaces specified using the Interface Design Language (IDL). With this black-box approach, it becomes quite difficult to embed special client side logic (such as a caching policy) or change the network interface without changing the application interface. The usual solution is to write wrapper classes, but this is often inelegant.
CORBA mainly addresses the fairly uninteresting problem of translating the arguments of a method call into a message and processing the reply. There little or no support for embedding logic as to what to DO with these messages so as to present a more intellegent interface to the application.
An example of a very intellegent interface with client-side processing is the implementation of the VOS type "property" with typechain encoding. Typechain allows one to specify a series of transformations on a data stream to decode it into its final form. For example, one could transmit gzip compressed data specified as "gzip;text/html", this means that to get the desired html document one needs to first decompress it with gzip. Another example is "url:image/jpeg" where the property that is transmitted is simply a URL, but it is "decoded" by seperately downloading the data at the supplied URL. To the user application this decoding is completely transparent and embedded into the implementation of property.
A: Most systems define objects strictly by their interfaces. The set of types on a vobject may be used to imply nearly anything about an object. In addition to method interfaces, a frequent use is how to interpret the object's postition in a vobject structure. Other object systems like CORBA do not have any structural object interlinking information.
A: A there are a couple major differences. The first is that VOP is ascii/XML based (see the example is below), and thus convenient to understand and debug. This also makes it vastly easier to generate from something like a lightweight perl script.
The second major difference is there are several macro features built directly into the protocol. This includes a macro definition/substitution syntax, which allows one to create a higher level protocol by predefining message templates of which can then be used by filling in only what changes. Another feature is the ability to use the contents of known message replies in the contents of later messages. This makes it possible to automatically process chains of messages which would normally require a back-and-forth conversation between two nodes. Here's an example:
<messageblock>
<message method="create-object"
nonce="1330573317">
<type>property</type>
</message>
<message to="$1330573317(path)"
method="property-replace"
depends="1330573317">
<data>1 1 1</data>
<datatype>text/x-vector-float</datatype>
</message>
</messageblock>
The first message requests that the receiver creates a new VOS object (termed "vobject") of type "property", with a message id (called a nonce) of "1330573317". The reply to this message bears this nonce (to match replies with the initiating message) and contains the details of the newly created object. The second message sets the object's value as a property to the data field. Notice the "to" field. What this field means is that in it should be substituted the value of the "path" field of the _reply_ message nonce "1330573317". So $1330573317(path) means "substitute this expression with the path field of the reply message bearing the nonce 1330573317".
This operation is done entirely on the receiving side, so that the sender could be a totally dumb client (netcat, for example :-) This isn't a trivial feature, because it is the basis of VOS object save-state files --- the save-state file essentially consists of a VOP session which, when run, re-creates the old state.
A: Granted, CORBA has the weight of industry support behind it, but by that reasoning we'd all be using Microsoft Windows, no?
VOS is implemented in C++, and presently there exists full Perl bindings for VOS which allow one to access nearly every feature of the system. We intend to create VOS bindings for other languages as well.
Q: "Hierarchical organization of network-distributed virtual objects" seems to be unique, but why not build on top of existing standards?
A: We feel the standards arn't up to the task. CORBA does actually have a naming system called COS which is in some ways similar to our built-in naming system, but because it isn't a required component (it is an entirely seperate service) it lacks some important advantages of being built in (not the least that you can't even rely on it being there!)
The design goal of VOS is to support Multiuser Virtual Reality, but additionally to be general enough to support all the applications presently being done with the World Wide Web and a lot of other stuff besides.
A: CORBA doesn't have all the specific services that we felt belonged in the messaging layer, and due to the nature of those services it would be extremely inelegant to implement them on top. These services include encryption and authentication (which VOS implements using Transport Layer Security (TLS) or Secure Sockets Layer (SSL)) and in particular the low-level object interlinking (our naming system) should integral parts.
A: That depends on whether you want a high level vobject-oriented API (which the C++ libary and Perl bindings support) or just want to acomplish some very specific actions (a small hand-written script.) A trivial client can be pretty stupid, because it knows in advance what messages to send and to expect. In particular, by using the substitution features of the protocol, the client can avoid having to process a lot of reply messages by specifying exactly the contents of the reply that it intends to use in following messages.
Q: Is the Virtual Object System at all related to the Stratus Virtual Operating System?
A: No. It also has nothing to do with the Veritas-Oracle-Sun initialtive, the Virginia Orthopaedic Society, the Vos family, or parrots.
Q: Are MetaObjects in VOS at all related to the "QMetaObject" class in QT (http://www.trolltech.com)?
A: No. The term MetaObject has many meanings in software and computer science, and the VOS MetaObject class is only vaguely related to some of them. VOS' Metaobjects have nothing to do with QMetaObjects in QT (except that perhaps you could write software that used them together in a clever way).