1.4. The 3D web

By "3D Web" we do not mean that VOS must be built on web technologies. Rather, this means that VOS has a similar scope: in the way that the web has come to utterly dominate hypertext and most forms-based applications, VOS will be the framework in which most online 3D applications will be built. This means taking cues from what has worked and not worked in the relm of the web, applying lessons learned from the technology, and interfacing with web-based technologies where apropriate.

One of the key innovations of the web browser is that it is sufficiently generic that people have been able to implement all sorts of amazing applications using the capabilities it provides. There is a reason why a few years ago people were talking about Netscape making the underlying operating system irrelevant! What I want to build into VOS is the same kind of flexibility that makes the web browser such a powerful meta-application -- but with a focus not on 2D hypertext, but interactive, multiuser 3D applications.

Why not build a 3D application within the web browser, as others have tried to do? Well, VOS is built on the observation that there are three basic limitations of HTTP which have caused 10 years of pain, suffering and hacky workarounds for developers trying to build interactive applications over the web. These are that HTTP is a stateless protocol, that URLs represent opaque handles to resources, on which no reliable introspection is possible, and that HTTP is explicitly asymmetric so that a server typically cannot initiate sending new data to a client.

For interactive applications, these are very sticky problems. We need to be able to track who a connected user is and what they are doing, we want to be able to look at a URL and figure out (possibly by performing additional queries to the server, but still in a uniform way) what it links to and in what context (is it a sector, a 3D object, or a image representing a texture?). We need to be able to push updates such as avatars moving around or new objects being added out to connected users quickly and easily. Most of all, this all needs to be very fast and scale to thousands of concurrent users.

The VOS approach is twofold. First, to work with explicitly stateful persistant connections, where the client and server are peers and are not differentiated on the protocol level and can initiate sending messages at any time. Second, that resources in VOS follow a richer object model than that of a flat file, and this allows a greater degree of introspection such as determining how a given object is connected to other things in the system.

Traditionally, 3D applications such as games rely on having the world downloaded or provided on a CD to the user ahead of time. Everyone is playing in the "same world" but that world is mostly static -- you can't start digging a hole, chopping down trees, building new houses etc because the functionality to push those changes to other users is not there. Instead, the protocol only works in terms of "entities" -- dynamic objects like players, mosters, ammo crates and so forth. Anything that is not set up to be a dynamic object, isn't. Furthermore, most 3D applications require a custom-written client, so there is high overhead involved in extending the client and server to add new capabilities, such as user interfaces for new features.

The goal is to have one client that can be easily reconfigured, download new worlds and adapt to new applications. At minimum the potential applications includes games, 3D user interfaces (this would provide an environment where prototyping such novel interfaces is quick and easy), data visualization and social communication.

It is with these goals and design requirements in mind that we present the Virtual Object System (VOS)[1], an infrastructure designed to support development of open Virtual Reality (as well as other services) on the Internet.