About‎ > ‎

FAQs

What is the difference between Open Cobalt and Croquet?


Croquet is a software developer's kit for creating collaborative 3D applications that was under active development from 2002-2007.  It was released as an open source SDK in 2007.  Open Cobalt is an application built using the Croquet SDK and is the only active open source line of development of that original technology.


Is Open Cobalt a virtual world?

No, not really. It is a virtual world browser and toolkit for creating your own virtual worlds.  It may be helpful to think of Open Cobalt as a tool for accessing and interacting with virtual worlds that can exist locally on your computer or anywhere on a network - rather than as a virtual world in itself.  This is not any different than how you might think of a web browser as a tool for accessing and interacting with web pages that can exist locally on your computer or anywhere on a network - rather than the web browser being a web page in itself.  When you launch Open Cobalt for the first time, it loads a private home world by default.  The Open Cobalt distribution also includes several very basic sample worlds.


Why is Open Cobalt built on Squeak?

Squeak has a balance of key capabilities that aren't presently found elsewhere.  Squeak is an open, highly-portable Smalltalk-80 implementation whose virtual machine is written entirely in Smalltalk, making it easy to debug, analyze, and change. In order to develop an infrastructure to support a large scale network of interconnected virtual world spaces, we needed to leverage capabilities that could only be provided by a true late bound, message sending language. Open Cobalt's relationship to Squeak gives it the property of a purely object-oriented system. This allows for significant flexibility in the design and the nature of the protocols and architectures that have been developed for Open Cobalt.
An essential part of Open Cobalt's development process is made possible by Squeak's ability to keep the system running while testing and especially while making changes. Squeak allows even major changes to be performed incrementally and they take no more than a fraction of a second to effect.

Another key feature of Squeak is its generalized storage allocator and garbage collector that is not only efficient in real-time (so that animations and dynamic media of many kinds can be played while the garbage collector is collecting), but that allows reshaping of objects to be done safely. Furthermore, Open Cobalt’s TeaTime messaging framework works by running the same computation identically (replicated) on different nodes (necessary for very large scale collaborative systems). This turns out to be a major constraint in the modern programming languages arena as most languages and hardware are oriented towards running as fast as possible at the expense of deterministic computation.

An example of this kind of problem is in the floating point number system (FP). Modern 3D infrastructure such as OpenGL and Direct3D relies heavily on FPs for position and other geometry information. Unfortunately the various platforms do not implement FP to the same accuracy or quality. This means that in a cross platform environment FP calculations will not have the same results and the replicated computations will diverge in state.
Calculations could be done using exact math and converted, but at a significant performance hit. You also have to watch for optimizations that will cause the answer to diverge. Changing the FP system is problematic for most languages for both technical and political reasons as you'd have to convince either a BDFL (Benevolent Dictator For Life) or a committee that it is an important change. Squeak Smalltalk, thanks to it's VM implementation and community open to new approaches, does have FP that is as close to deterministic as the hardware allows.

Why not use Java for Open Cobalt?

When we first set out to build Open Cobalt's underlying Croquet architecture, we intended to do it in Java. However, we had to abandon that approach because Java lacked needed meta facilities.  Open Cobalt relies heavily on the Smalltalk meta system and accessible internals. For example, part of the Open Cobalt system is #future interface for sending messages into the replicated islands. It is an uncluttered interface that reads naturally. Now consider the issues of translating this into Java.

First, Java will not let you write a general "message interceptor pattern" which means you're going have to rewrite the sending sequence repeatedly in the calling section instead of the graceful encapsulation #future provides. Secondly, Java requires that you statically type everything, greatly increasing the complexity of marshaling and unmarshaling arguments and of the support code required. Now consider implementing a timed message queue; you'd have to write inner classes with serialization for any future message. All that effort, compared to the intuitive #future mechanism implemented in Smalltalk.

Java has other problems as well. Since the Oracle acquisition of Sun, its future direction is uncertain (they've already shut down Sun's Wonderland effort and un-open sourced OpenSSO and changed the license on Open Solaris).  Java is also a slow language to develop in because even the best of the toolsets are not well integrated by dynamic language standards. Doing code turnarounds on servers is very difficult and cumbersome and often all of the relevant code must be redone as XML configuration files which have the virtue of easy changes and sidestepping all of the carefully set up static type information.  All this made it unusable for advancing large scale replicating systems.

Smalltalk has been around for years, isn't it a dead language?

Smalltalk is far from dead.  There are currently at least 28 independent implementations of Smalltalk in various states of activity. Of these, at least 10 are current, with VisualWorks, Squeak, Pharo, ObjectStudio and VAST most commonly used (not to mention the NSF-funded Open Cobalt effort). Up until the release and promotion efforts around Java, Smalltalks from all three of the major Smalltalk-based software vendors had a reasonable amount of the "enterprise" software development market. Unfortunately the Smalltalk market outside of that was tiny due to large per seat licensing charges by Smalltalk software vendors in combination with a tendency among those vendors toward closed and proprietary implementations that insulated the common user from having access to working code.

One of the aspects of programming language acceptance that has become apparent since that time is that having free (and preferably open source) versions that developers can download and explore is extremely important...and Smalltalk in that period did not meet that need. Then came the Sun-sponsored Java with free versions and Sun's very well thought out and financed marketing campaign to advance the Java programming environment. At the time, Java was seen to be a more accessible language that was targeted at the average programmer who could download and try it out for free.

Not being sponsored by a major corporation, Smalltalk did not at the time have an equivalent marketing push and as a result suffered a major setback in its use. Despite the rise of Java, there continued to be a substantial legacy base of Smalltalk code as well as a large community of interested developers.  A resurgence of interest in Smalltalk occurred with the introduction of Squeak-Smalltalk, a free and open source lineal descendant of the original Smalltalk-80 (initially developed by Alan Kay's research group at Apple). The existence of Squeak-Smalltalk 1) forced commercial vendors to follow up with free releases of their products, and 2) made it possible for the Smalltalk community to begin growing outside of the areas of large-scale enterprise implementations.

Today, Smalltalk is experiencing a growth in usage and developers.  The open source Smalltalk mailing lists have a healthy amount of traffic and the various public source servers grow daily. There is new code being written in Smalltalk, much of it open source and the remainder involving internal corporate efforts with little visibility (such as in the banking industry). There has also recently been a general revival of dynamic languages (eg. Python, Ruby) which have deep roots in earlier Smalltalk work.  This has led to a new expansion of interest in Smalltalk and new projects such as the radical Seaside web framework, CodeCity, and DabbleDB. An interesting recent note is that in the 2010 Google Summer of Code the European Smalltalk Users Group was funded, while approaches using other languages like Ruby and PHP were not.

Calling Smalltalk dead brings up the question of just what that means? Does it mean there are no maintained implementations? Does it mean no one is using it? Does it mean no new code is being produced in it? Does it mean that since it's over 30 years old it must be dead? This argument is so vague that it can be regarded a general sign of an unannounced agenda - one that is usually advanced by people who are personally invested in another technology or who fear matching a solution to meet a need. And finally, the dead-because-it's-old argument can be disregarded on the basis that there are other old languages that are still in common use: C, C++, various Lisps, Forth, etc.

For more on Smalltalk click here.

Gartner perspective on Smalltalk.

How does Open Cobalt work without a server?

Open Cobalt works by leveraging a peer-based communications protocol to synchronize identical simulations running on a distributed set of machines.  In this way we make it possible to have the same things happen on all the machines participating in a shared, replicated virtual space.

Objects interact in shared Open Cobalt spaces by scheduling messages for future execution. The scheduling mechanism hands future-send messages off to a message router process on one of the clients (the 'owner' of the simulation).  There the messages are timestamped and broadcast to all participants. On receipt of the timestamped message at a participant it is executed. If a side effect of the execution of a message was to move a virtual object in the simulation, then all of the participants would move the same virtual object at the same relative time.  If the message was to store data to a local file, then all of the participants would write the same data to a local file at the same relative time.

What is the Open Cobalt virtual machine?

The Open Cobalt virtual machine is essentially the same as the Squeak virtual machine.  It acts as an interface between Squeak code and the microprocessor. It's written in Slang, a functional subset of Smalltalk that can be translated into standard C. Squeak uses the C language as a cross-platform equivalent of assembly language. Since Slang is a subset of Smalltalk, the Squeak virtual machine can be edited and debugged by running it in Squeak itself. The virtual machine can also be extended with plug-ins that are written in either C or Slang. These are used in Squeak for such things as playing media files and for supporting Squeak's built-in public key encryption abilities.

What hardware and OS do I need to run Open Cobalt?

Open Cobalt currently runs on Intel-based machines, including the modern Apple range of machines. Various versions have been created to run on 32-bit Windows (XP, Vista, 7), Linux, and Mac OS X. There are various audio and video driver issues with running Open Cobalt on Linux, but anything capable of providing OpenGL 1.5 level or better will usually work. The User Guide describes further requirements, and this answer will be expanded as better information becomes available.


How can I access virtual worlds that other people have created?

Answer to appear shortly...


Comments