The OpenCroquet Project

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

Late 19th century paintings of croquet-playing ladies are a somewhat unusual visual advertisement for a multi-user software design environment. But if we were to express OpenCroquet's qualities in a few words, it would be "a true collaborative internet-enabled three dimensional design environment". And the collaboration should be as smooth and unhurried as a game of, well, croquet.

OpenCroquet is planned to become such an environment. Based on Squeak, a Smalltalk-80-based multimedia design and studio, it continues the Xerox-PARC tradition of building software environments that enhance the human ability to think while avoiding machine-based constraints. Squeak and OpenCroquet are led by some of the original Xerox-PARC crew, first and foremost Alan Kay.

Although OpenCroquet is billed as an extension of the more mature Squeak environment - Squeak reached version 3.7 in December - OpenCroquet is far more than a plug-in or a software module. The currently downloadable version has the rather dispiriting version number 0.1; for the moment it relies on Squeak 3.6, not 3.7 and the OpenCroquet installation installs its own Squeak environment. Also known as the "Jasmine" release, it is accompanied by the usual health warnings, but anyone with a smattering of Smalltalk or Slang and a broadband connection would find it easy to muck around with the code and run most of the environment without too many problems.

Squeak is a fully object-oriented programming and authoring environment, and anyone familiar with it will find many of the graphical primitives and some of the GUI features available under OpenCroquet. Squeak permits both scripted and purely GUI-led creation of new objects. Changes to the runtime environment during object creation will not interrupt the underlying Squeak virtual machine. This is mostly due to the storage allocation algorithm and the realtime garbage collector working within the VM.

OpenCroquet does not only take advantage of Squeak, it is the result of a comprehensive re-architecting of the very idea of internet-enabled collaborative environments. Web interfaces and classic IP-based protocols allow for some collaboration, but collaborative interfaces are usually document-based, or rely too much on analogues to phone messaging. OpenCroquet is emphatically 3-dimensional, and it employees peer-to-peer networking that is not compromised by the existence of a central server to simplify the updating of object hierarchies.

It is also uncompromisingly object-oriented, taking messages between objects as the main communication and update mechanism. Smalltalk and some operating systems have taken this approach very seriously, but in a 3-D environment where the very interface is just another objects whose behaviours can be changed by programmers at any time, the very size and content of messages broadcast from object to object carry substantial implications.

All objects are accessible to other users and all users participating in a particular shared space can modify all objects present in that shared space. All objects are replicated across the shared space, thereby making it simple for all users to work in the same interactive 3-D space. Objects are always versioned, something that is achieved by embedding a timebase in the communication protocol used by OpenCroquet.

TeaTime

The central ideas behind OpenCroquet object communication are contained within its multi-user communication architecture, also known as TeaTime. What is important here is the fact that it isn't just data that aren't replicated across the OpenCroquet system, but also computations.

This is why synchronization protocols are extremely important. OpenCroquet needs to complete all visible (and audible) I/O-based effects before all messages are communicated to all collaborating objects within the shared space. For instance, all screens show identical interfaces, even though the perspectives might be different. How the computations are executed is entirely the responsibility of the individual object. How the computations propagate to every instance is due to the protocol being used. But it isn't usually a problem to propagate the messages to replicated objects, since they are likely to encounter an object state identical to the one the previous object was in before the computation was initiated.

But the object state update happens in two stages, not one. First, the behaviors of all of objects participating in an event or action are computed and all objects have to wait for the computations to end by a certain deadline. Then all behaviors are committed atomically. This point is re-iterated in the excellent documentation available the OpenCroquet website and it should be taken into account when new OpenCroquet applications are coded.

If the object behaviors (or methods, to stay in OO terminology) do not meet the deadline, all calculations executed by objects resident in the shared space are stopped and discarded.

There is another benefit to the historical data kept by the object. Distributed 3D environments suffer from risks caused by possible network disruptions or unpredictable user behavior. This might lead to objects or users being cut off from the shared space. The historical data are supposed to enable individual objects to recover from disruptions to the environment. This can be due to a number of factors; given that software and hardware underlying any OpenCroquet shared space is likely to be heterogeneous and that networks can be volatile, distributed object protocols have to have recovery mechanisms built in.

Any 3D distributed programming environment has to be easily intelligible to non-graphics programmers. 3D designers using tools like Blender should be comfortable creating collaborative objects for, say, electronic learning environments. OpenCroquet components are collected in the so-called Teapot suite; they provide access to the OpenGL rendering engine, event handlers and simulation objects that are part of the TeaTime architecture. The graphics methods provide the user interface elements; since we are talking about a 3D environment, all rendering behavior that is included in a rendering frame has to include far more information than other user interfaces would usually require, including the user's and the object's position within the shared 3D space. The so-called Tframe class gives complete access to the OpenGL library.

Events are communicated by something that is analogous to a user camera ("TuserCamera"), while objects are tracked via a 3D analogue of mousepointer. Keystrokes can be mapped onto both 3D objects and embedded 2D objects. The graphics engine has been implemented in Squeak, which is somewhat surprising given the typical graphics programmer's predilection for C and C++. Its speed is not impaired by this choice in any way.

Simulations manage fairly complex behaviors, and are coded separately to avoid imposing too much rendering overhead. The outcome of methods would be calculated continuously; once an individual calculation is completed, a message is sent to be received by the object at some time in the future. This may sound like time travel, but is just good policy to avoid the constant rendering overhead enforced by recalculating present object state by referring to past object history.

3D collaborative environments tend to have fairly straightforward applications from collaborative engineering projects to multi-user learning environments that go beyond grading and the use of spreadsheets. Of course, previous 2D interfaces are not completely ignored; Mozilla runs quite happily inside OpenCroquet. But as soon as object libraries and networking bandwidth is available, a wide variety of new uses can be implemented.

Index entries for this article
GuestArticles	Pohlmann, Frank

---

(Log in to post comments)