Open Croquet
Open CroquetCroquet is a project started by AlanKay, based upon SqueakSmalltalk.
Croquet was built to answer a simple question. If we were to create a new operating system and user interface knowing what we know today, how far could we go? What kinds of decisions would we make that we might have been unable to even consider 20 or 30 years ago, when the current set of operating systems were first created? -- AlanKay
The websites:
Croquet is a collaborative, LiveProgramming, audio-visual 3D environment that allows development of interactive 'worlds'. Important features:
Implementation:
Under the hood, Croquet is based on a protocol called TeaTime?, which keeps multiple servers in synch by the simple, expedient means of feeding all participants the same messages in the same order. Messages produced in response to these messages are assumed to be the same for all participants, whereas 'outside' inputs (like avatar movement) get distributed to all participants via a distributed TwoPhaseCommit protocol. Thus, the routing for external messages serves also as the synchronization mechanism. Users late to the tea party can request a snapshot - including code - and will process all messages from the timestamp of that snapshot.
Messages are typically scheduled for delivery at so many milliseconds in 'the future', though one can schedule for 0 milliseconds in the future. These future-messages get placed in the global queue, which doubles as a TailRecursion mechanism (since the stack won't grow too deep when recursing across time). There is something of a global time-message heartbeat provided by the router, which lets you know when it is time to run all messages with a timestamp earlier than the global heartbeat.
SqueakSmalltalk is the base language for the implementation.
Croquet interacts with OpenGl to provide its graphics, and OpenAl to provide its audio. When rendering, the locations, orientations, colors, shapes, and other rendering aspects of objects may be continuous functions of 'real' time; this allows carefully developed animations to run smoothly with reduced need for sequential updates. Meshes can be added to the world, imported from a number of sources (OpenCobalt? includes a .kmz import that wil work with Google's 3D warehouse). Large multi-media files (textures, meshes, and sounds) are typically stored in Croquet with a very degraded (low-resolution) quality, but then can be accessed via a distributed hash-table, such that users don't download content they aren't interacting with. Video streams and such are usually handled outside Croquet itself to reduce synchronization costs (i.e. don't want a distributed 2-phase commit for every video frame!).
The GarbageCollection and allocator for SqueakSmalltalk has been upgraded considerably during the development of Croquet.
Weaknesses:
Neither TeaTime? nor Croquet nor Squeak is designed for security. This isn't a real problem unless your motivation is either (a) 'open' distributed worlds where untrusted strangers can join and participate, or (b) production of interesting games - which usually requires hiding some information from some participants. Point (a) can, fortunately, be mitigated a bit: you can save a world and restore it later. OpenCobalt? has added a simple authentication mechanism that will at least keep unwanted users out of an island, though they still can do anything once they are in it.
The current model of world organization requires that individual worlds be single-threaded. This isn't too problematic, since one can scale by using multiple worlds instead of larger worlds, but it does limit the practical size (in terms of complexity) of any given world, and can introduce a challenge for other interesting applications (i.e. developing worlds that compose other worlds by inclusion, inheritance, or transformation). It also means each user must have the whole world, even if they only want part of one.
The use of TeaTime? binds Croquet quite permanently to its implementation language, which must be fully deterministic (down to the bit level) across all versions. This can make some optimizations difficult.
If a world goes slightly out of synch, this problem can quickly grow as it processes more messages. Further, there are mechanisms that would allow you to inject a message to make the world go out of synch. Usually these mechanisms are used for "observational" purposes, such as rendering from the Avatar's perspective; they are used very, very carefully. Synch failure due to network problems is resisted by use of the TwoPhaseCommit protocol.
The UserInterface aspect of Croquet is somewhat awkward to interact with. In particular, there are issues of AutomaticVsManualPlacement. Croquet tends to require manual placement, which tends to force users to make a lot of trivial decisions (i.e. exact angle of a portal), allows features to be hidden or scattered. This further results in very information-sparse "worlds". A typical webpage has more information per square inch. The 3D properties make for an interesting toy, and might help development of visual simulations for a virtual learning environment, but do not readily aide in bringing more information to the user in a manner suitable for serious work use.
Perhaps OpenCobalt? will help rectify some of the above problems, by providing more uniformity of interface and implementing some scripting languages atop Smalltalk.
The OpenCroquet pre-alpha which was briefly available on the net provided a cross platform, shared 3D collaborative workspace which allows users to modify their own environment while it is running. Spaces can be linked together via 'portals' which work much like hyperlinks. Like the WWW, you can build your own 'spaces' and others can link to them. You can think of it as a 3D WWW built on something like LISP instead of HTML; with a scripting model that is usable by 10 year old children, and a universal browser available for just about any platform - which runs bit-identically on all of those platforms (the pre-alpha runs on OS X, Windows, and various flavors of *nix - basically any platform that Squeak runs on which supports OpenGL based graphics in the hardware). Anyone who has read Gibson or Stephenson could probably think up a few good uses for this sort of thing.
The pre-alpha was not really meant for broad distribution. There are plenty of folks out here eagerly awaiting the release of the Open Croquet alpha at some point in the future. I would recommend taking a look when it is released.
RK sayeth unto us mere mortals: Chatrooms and IM will be obsoleted by a medium that unifies (not integrates) all of the capabilities of the wikis, usenet, IRC, and email. This medium will provide new and novel capabilities which none of the current crop of media provide either alone or in combination. Compared to this, a horrific 3D UI over standard technology (OpenCroquet) is trivial and uninteresting. Your continued praise of this trivial hack merely serves to demonstrate the poverty of your imagination. Apparently he's not fond of OpenCroquet because it isn't BlueAbyss.
Loaded the thing and run three times successfully. Always get lost in a world and can't get out except quit without save. How to get back to dock or home is not apparent. Crashed system, but not machine, a few times. Could be paradise for gamers.
Personally, I believe this is the way of the future. I've had great success making business contacts and friends with InternetRelayChat. I'd like to extend that to an equivalent 3D environment. Even better would be some SelfLanguage features like easily shared {code,app windows,dirs,etc}. -- ShaeErisson
It is the wave of the future, 3D environments will eventually replace text based chatrooms.
I wonder how the bandwidth requirements compare between IRC and OC?
Looking at http://glab.cs.uni-magdeburg.de/~sqland/Croquet0.1.pdf, Section 11 (pp. 66-68) is interesting, but cryptic. I don't see how the object-time-message model is supposed to work. Is there any more about this aspect of it? -- TomCargill
There's an online lecture from Alan Kay at stanford, don't have the link handy, where he discusses this in detail. Just search the online lectures.
Does anyone know how the OpenCroquet project is doing? I keep looking for an update on it (even a simple everything is going fine, we're still working on it kind of update) and can't seem to find it.
Here is an update from April 2004 - http://gruenderlabor.cs.uni-magdeburg.de/pipermail/croquet-user/2004-April/thread.html
The latest Croquet FAQ indicates an Alpha version of Croquet will be available to the public 1 September 2004 - http://www.croquetproject.org/About_Croquet/faqs.html#23
As of August 2009, OpenCroquet is no longer under development. All development is now part of OpenCobalt?.
On the purpose of OpenCroquet: The project is the thing you are looking for! It is to establish a standard; for an interactive environment in three dimensions, not necessarily represented on a 2d screen, for peer-to-peer communication in the way that the web is peer-to-peer, connecting multiple servers via hyperlinks/portals. Screenshots, their own implementation and interpretation of the standard are subsidiary to the goals of the project.
My personal view of it is of a next-generation world-wide web or http protocol, sharing data in a less document-oriented way than the web, and far more interactive.
3D UI just for the sake of it is an extremely ugly idea, as it is to people like me and probably others, extremely obvious that the 3D layout just gets in the way of us getting things done. It's just not functional, and this could probably be demonstrated by tests with real user. What I know is for example no professional chessplayer uses the 3D chessboard available in all chess playing programs (yeah, it may be nice for kids). But manipulating 3D objects with a mouse on a 2D screen is extremely annoying when you don't have to. The visualization of the chess board in 3D is also of a significantly worse quality no matter how smart OpenGL gimmicks are used by the program. An object rendered to create the illusion of 3d has less pixels, less visibility, etc,etc,etc. It is a bad idea altogether. People are very much used to run their intellectual activities (reading, writing, programming, mathematics, etc) in 2D because it seems so much more efficient.
It is frustrating to see bright people just assuming that 3D is better because it's 3D. So 3d becomes a target in itself when the target should be usability and productivity for the user.
There are numerous examples (i.e. anything promoted by TedNelson) of VeryBrightPeople? deciding that some architectural detail is equivalent to goodness, and designing systems around that architectural detail. Oh, and not doing any "customer validation" to see if users think what they're working on is useful - this particular category of VeryBrightPeople? thinks that TheCustomersAreIdiots. (In many cases, they think that the academic community at large are idiots as well, for not working on the things that they think ought to be worked on).
That said, AlanKay isn't TedNelson - the two have some similarities, but also numerous differences (Kay is nowhere near the narcissistic self-promoter that Nelson is; and Kay has actually produced something useful); and research for research' sake is not in and of itself a bad thing. If AlanKay wants to work on OpenCroquet, I certainly won't try and stop him. I too have my doubts as to whether a ThreeDeeInterface (this or any other) will become ubiquitous. One thing I'm sure of is that if 3-D does become a useful UI paradigm, it won't be because of any single individual or his team. It will be due to the continuing advancement in the discipline brought about by millions (yes, millions) of man-hours of research and development, by scientists and engineers around the globe, working independently or in concert. AlanKay may well play a key role, or he might not.
Here I was thinking that the actual aim of Croquet was not to be a 3d environment, nor a peer to peer network, but as a way to collaboratively develop software, where at all times all nodes in the network are running with the latest version of the software due to the replication technology built on top of the peer-to-peer concepts. I guess I was way off target. Everyone else sees it as a pretty environment and a p2p tool. For me, those are merely distractions. The concept of creating a network of servers which are all dynamically updated seems like a pretty neat way to handle deployment issues. Not to mention a great way to pair program.
Can you provide details? Especially about security issues such as how to ascertain that an update made by such and such person is legitimate?
That was my question as well. No, I can not provide details regarding validation of sources. I'm sure the security aspect has been thought about/implemented. We'll see anyways. Supposedly a developer release is due out today (2004-10-11). Thee is still 5 hours left before midnight in the USA, so they haven't missed the publicized release date, yet.
But touching upon the security aspect once more, I can not see how a collaboration/code sharing tool as this could work WITHOUT security and/or author/source verification being one of the central, if not THE central components in the system. It just wouldn't work. Unless I'm missing something.
If you ever put real security into Smalltalk, that would be an important step forward in computer science all on its own. But despite AlanKay's willingness to sing his own praises, there's been no mention made of SmalltalkSecurity. So I'm convinced they haven't done any such thing.
Well they surprised me and managed to release on the day they said they would.
http://www.opencroquet.org/Croquet_Technologies/downloads.html
From the documentation, which is a lot better than it once was, there is no real security. They've got some vague talk of a web of trust but nothing describing how it's supposed to work. I didn't know whether to laugh or to sob when I read "The approaches and techniques used may have broad applicability in helping to control the unlicensed distribution of copyrighted materials".
If you want to understand what OpenCroquet is about, try this:
"This is so lame," you say. "No way am I going to log on to a MOO or MUD. That was kid stuff in 1992; now they're all on SecondLife." But wait...
In a MOO, you might be in a room with a television set, and a door to the west. If you look at the television set (by typing "look tv"), you might see that it has dials and an antenna, and that you can turn it on by typing "turn on tv". However, if you type "@list tv:"turn", you see the code for that verb. In fact, if you type "@dump tv", you see the code for the entire object. Supposing you are the owner of the TV, you can invoke an editor on the spot and immediately change its code, or add new verbs ("smash tv"). As soon as you commit your code changes, the behavior of the object is updated. Meanwhile, 100+ other users are milling about chatting, playing with objects, and creating new objects, all through textual commands like "look at jessica", "wave jessica", "take robot from bookcase", "throw robot at xie", etc. However, everything on the MOO is implemented as an object in the VR database, including rooms, doors, players, pez, the sky, and so on. The owners of those objects can alter them at will, and essential objects, such as the generic player class that everyone inherits from, are owned by the equivalent of "root". In fact, the MOO server itself implements a small VM, complete with cooperative multitasking and the equivalent of a database, and the verbs on objects are programmed in a JavaScript-esque language. Like Smalltalk code, MOO code doesn't make too much sense in isolation, since all MOO objects inherit from other objects, and a verb on a given object almost always calls verbs on other objects in order to do things. For example, if the TV blares out a message when it turns on, the code might look like "if(!this.on) { player:tell("The TV blares, 'News at 11.'"); }", where "tell" is a verb on the player who turned it on. Even the code that processes user logins is in-MOO; the MOO server itself only establishes the network connections. Thus, it is possible to completely change the way the MOO authenticates users without patching the server. There is also no law that says a MOO has to have any "rooms" -- it's conceivable that MOO could be used as a shell for a web RPG or as a means of cataloguing zoo animals.
OpenCroquet is basically a 3D MOO system, with SqueakSmalltalk as the language and VM, and since it has the full power of Smalltalk behind it, a shared VR space implemented in Croquet has more capabilities than one implemented in MOO (graphics aside). The reason OpenCroquet seems to have been hard for the people posting above to understand is because it's so abstract. It's a framework for building cooperative, 3D spaces. Theoretically, you could reimplement Second Life on top of Croquet, or rather, multiple SecondLifes that could talk to each other.
EditText of this page
(last edited February 2, 2011)
or FindPage with title or text search