At the C5 Conference

Well, most of the crew is here at the beautiful Granvia Hotel in Kyoto, Japan. Alan, David Smith, Andreas, and Mark are just down the hall. We are all taking a break in the midst of the Third International Conference on Creating, Connecting and Collaborating through Computing (C5 2005). This conference is emerging as the primary venue for those working with Croquet. It is intended as an international forum for the discussion and presentation of creative and collaborative environments among researchers, developers and users of collaboration technologies, learning environments, and object-oriented languages (especially Smalltalk, Squeak and Croquet). This year, there are a total of six papers that deal primarily with Croquet. Alan gave the keynote entitled "The ARPA Dream Revisited". Mark and I then gave our two papers on user interface approaches for higher education authoring/learning environments. Immediately afterwards, David Smith rocked our worlds with a demonstration of Filters and Tasks in Croquet. More on that in a future posting....

Croquet, Everyone?

The following article written by Quentin Hardy and entitled "Croquet, Everyone?" just appeared in the technology section of Forbes Magazine's January 31st issue:

"Alan Kay, a legend in computing, thought it was time for something better. So he built it.

Thirty years ago Alan Kay oversaw the creation of many of the personal computer's clever innovations, among them windows, point-and-click file opening and networks. His lasting success irks him. "Except for the silicon, we've only gotten 5% of the potential of the PC revolution," he says.

Kay wants to take computing forward with his next great invention, an operating system that puts the user in a three-dimensional graphic world with scores of other users, all computing collaboratively and communicating through audio and visual messaging. Called Croquet, it runs on top of operating systems like Windows, Linux and Apple. Its innovation is in relocating the now-decades-old interface of windows and folders to a shared virtual world. You can landscape it any way you want, with mountain ranges, oceans or meeting rooms. Users become color icons or, if you'd rather, 3-D characters such as fish or bunnies. You zoom around in this rich, icon-filled space and call up digital photos, Web pages, science projects or PowerPoint presentations.

You can view and alter other users' files in one place, chat with those other users over the Internet and then move on to far-off objects and people, if they seem interesting. A budget report's graphics, say, might be made a figurative 10 feet tall, then changed by one user to reflect new sales data, then recolored by someone else for sharper resolution. You can do all this even if your Internet connection is a creaky-slow dial-up modem.

Croquet packs a lot of power for a little piece of software, one with but a single line of code for every 300 in Windows XP. Kay built Croquet with help from six crack programmers, funding it first with his own money and then through Hewlett-Packard's research labs, where he is a senior fellow. The total cost for the project, released for free last October, is less than $10 million, a drop in a Microsoft bucket. Says Kay: "Good math and small teams win."

In the 1970s Kay, now 64 years old, was an early member of Xerox's famous Palo Alto Research Center. Some of his inventions from that time, including an object-oriented programming language called Smalltalk, went into Croquet. He later worked on 3-D graphics at gamemaker Atari, compact computing systems at Apple Computer and easy-to-use interfaces at Disney.

Croquet comes as many institutions struggle with large, spread-out teams. The U.S. military is evaluating Croquet for training radio technicians to build field communications systems in virtual terrain replicating the landscape in Iraq. This spring the universities of Minnesota and Wisconsin will try Croquet for collaborative classroom labs. Intel, whose average employee is at any time on three different projects, is looking at Croquet as a way to make juggling work projects gamelike.

HP is playing Croquet by giving it away as an open-source project to build a user base quickly and to get an early read on what this sort of software will be useful for. "We don't get too focused on how to make money yet," says Patrick Scaglia, Kay's boss at HP. "We'll know within a couple of years. Good ideas take off rapidly, or they die.""

Elevator Pitches

Elevator pitches are 30 second explanations of ideas. Croquet still needs a good one. Its not for lack of trying that we don't yet have a good one. This is because it is a very complex idea with many parts. What we probably need to do is tailor a set of pitches with each one oriented towards a particular audience type.

As noted earlier in this blog (Like an Elephant), the perception, if not value, of Croquet is very much different to different people. So, I thought it might be useful - and perhaps a bit entertaining - to have us use this blog as a way of collecting some elevator pitches from the members of our emerging community.

So here is the challenge: Please post to the comments what you believe to be an good elevator pitch for all or some aspect our project. It would be great if you would sign your contribution.

Should be interesting...

Dump the World Wide Web!

Here's an interesting excerpt from an article written by Bill Thompson that appeared on the www.opendemocracy.net website on December 23rd, 2004. What Thompson is saying has a good deal of relevance to what we are doing with Croquet. I will let the reader decide on where that relevance might be. Comments on this posting are particulary welcome.

"The World Wide Web is dead. Like a cartoon character running off a cliff but making it some way out into space before awareness brings gravity back into operation, it may continue to dominate our online lives a little longer, but its day is over.

Soon the whole clumsy, inadequate edifice will come crashing to the cyberspatial equivalent of the ground and we will look back upon the crazy decade from 1994 to 2004 for what it was – a dead-end in the development of the networked world.

The reasons are simple: the web, like many a political refugee, lacks a state. What’s worse, it doesn’t speak a language that will let it express anything more than basic requests for food, shelter or yet another poorly-resized JPEG image. Like all analogies this one breaks down pretty quickly if you scratch it too hard, but it’s worth keeping in mind during the (necessarily) more technical explanation you’re about to encounter.

It is important to understand how the web works. The web, like email, uses a “client-server” model. The client, in this case your browser, requests something – a web page – from a server. When a request is received, and assuming the parts are all there and the client has permission to take them, they are sent over the network by the server. It’s then up to the client to deal with them appropriately. In the case of a web page the elements will usually be a document written using HTML, the hypertext markup language, some image files and maybe extra bits and pieces. It is all very simple, and it’s made even simpler because the browser and the server communicate using a language of their very own called the Hypertext Transport Protocol, or HTTP.

The browser takes what it is given and displays it on your screen, laid out as prettily as it can manage. However once we want to do anything more complicated than display a page of text and graphics on a screen we rapidly discover that both HTML and HTTP are simply not up to the job.

The problems with HTML are serious but understandable. When Tim Berners-Lee created the web he wanted a simple text-based publishing tool for the high-energy physics community, and a simple markup language that let authors specify headings and link to other documents was fine.

But in 1993 two graduate students at a United States university decided they could improve on Tim’s work by writing a new browser which would display images too. In order to make this work they had to change HTML by adding the < IMG > tag – and they started a process of non-standard extensions which continues to this day.

The result is the mess we see today, where despite the best efforts of the standards bodies it is still necessary to write dozens of lines of code at the start of a web page in order to figure out which browser is in use, so that the “correct” version of the page can be sent over.

Present at the creation

It’s an appalling mess, but it wasn’t directly Tim’s fault. However the same cannot be said for HTTP, the protocol which allows browsers to ask for pages and servers to send them across the network. Here Tim’s desire for simplicity has led directly to our current problems, because he decided that the server should treat each request for a page from a browser as a separate transaction. The decision to make HTTP a “stateless” protocol has caused immense trouble. It’s rather like being served by a waiter with short-term memory loss: you can only order one course at a time because he will have forgotten your name, never mind your dessert order, by the time you’ve had your first spoonful of gazpacho.

Unfortunately many of the things that we want the web to do for us, from online shopping to having a newspaper that tailors its pages to our interests, rely on some degree of long-term interaction between client and server. Cookies, small data files that are placed on a client computer by the server, provide a partial solution, rather like the tattoos sported by Guy Pearce in the film Memento, but they are inelegant, complicated and far from reliable. As, indeed, the tattoos turn out to be.

We have spent the last decade fighting against the limitations of the web standards, extending, breaking, reinventing and compromising with them to the point where you can just about do online shopping, make pages look reasonably attractive and even offer personalised services.

But enough is enough. Just as it is sometimes necessary to demolish old buildings to make way for new, so it is time to move on from the web. It isn’t as if we need to look far for an alternative – we’ve had one since 1990 when the web was just starting to emerge from CERN physics lab. It’s called “distributed processing” and it enables programs to talk to each other in a far richer, more complex and more useful way than the web’s standards could ever support.

Had it not been for the rush to embrace the web’s page-based publishing model, choosing the simple solution over the right one, we would have proper distributed systems available today. Instead we have to invent technologies which preserve the web approach while making it slightly more usable, like the eXtensible Markup Language, or XML. Any tool that is too embarrassed even to use the first letter of its full name for an abbreviation is surely in trouble from the start.

Unusually for a company which is credited with following trends rather than creating them, Microsoft saw this first. They never liked the web and it was only the horrible realisation that every company, every net user and every competitor was going to invest a vast amount of money, effort and resources making it seem like it worked that forced Bill Gates to turn the company around and give it a web focus late in 1995.

At the time their programmers were just beginning to explore the possibility of direct programme-to-programme communication and network-based collaboration between applications. Without the distraction of the web we may well have had widespread distributed online services five or even more years ago.

These services would not rely on the Web browser as the single way of getting information from an online service, but would allow a wide range of different programs to work together over the network. We already accept that email, chat and even music sharing do not have to be Web-based, but we can go much further.

A news site could deliver text, images, audio and even video through a program designed for the purpose, instead of having to use a general-purpose browser, or a shopping site could build its own shopping cart and checkout that did nor rely on Web protocols. And we would have no need for Google, because information services would advertise their contents instead of having to be searched by inefficient ‘spiders’.

The web may have served a purpose once, giving net users something relatively simple to look at and use and convincing the world that being online was a good thing, but it has done so at great cost to the network’s architecture and has diverted research into usable, scalable and functional distributed systems for the last decade.

There is a deep need among the users for something better than the shoddy, half-baked hypertext publishing model that we geeks foolishly embraced back in the early 1990s. If we do not start delivering it the net itself will stumble, fail and eventually die away, trapped in this stateless web of deceit."

NICT/UW-UM Collaboration

Our research groups at UW and UM have just entered into a collaborative research agreement with NICT (Japan's National Institute for Information and Communications Technology). The Croquet Committee is very pleased to have NICT recognize the potential of this new technology and to have them support important work in the development of Croquet. So, we are now off and running to achieve the following general objectives: 1) Adding user interface elements to Croquet for creating and retrieving annotations; 2) Adding support for importing and handling the placement of models and objects into Croquet environments; and 3) Developing user interfaces for allowing 3D content to be easily accessed from a digital repository or database and placed into a Croquet scene.

Developing this type of functionality for Croquet will go a long way in making it useful as a tool for education and training. The work is currently divided up into the following tasks which are scheduled to be completed this year:

1) Development of user interfaces for easy scene annotation in Croquet

• Researching and developing user interface conventions for adding notes to objects or locations within the 3D space (notes would be in the form of text, however, the technology will be developed in a way that supports video and audio annotations). Since all notes are themselves user-created objects within a scene, all notes may be added as annotations to existing authors' notes as well.
• Researching and developing tools to detect, view, and hide multiple authors' annotations. For example: a user should be able to view only the annotations that were made by a particular user or specified group of users.
• Researching and developing tools to define a path or course through a scene and identify selected annotations so that a tour of a scene and its annotations may be defined by one user and then followed by another user or groups of users.
• Researching and developing caching strategies to pre-fetch annotations and content when moving into a new region of a scene. For example: based on the user's position or level of authorization in the scene, the client would be able to dynamically fetch annotations that are not visible to other users lacking a similar position or level of authorization.

2) Development of graphical user interfaces for easily handling 3D objects

• Researching and developing the ability to import large and complex 3D models into a Croquet scene.
• Researching and developing a graphical user interface for rotating, moving, and magnifying objects in a Croquet scene.
• Researching and developing a graphical user interface for measuring, comparing, slicing, and moving objects between scenes (worlds).

3) Development of test content and capability of storing that content in a repository via the Croquet client

• Translation of existing open source/freely available sample content into appropriate format for implementation in Croquet spaces
• Creation of new (original) content for testing purposes
• Populating the digital repository (worldbase server) with new and translated content for testing purposes

4) Integration of annotations into a shared repository

• Developing a means by which users can be authenticated before allowing them to author content that can be promoted to the digital repository.
• Storing the author's annotations to a shared distributed repository
• Developing searching tools to locate author's contributions to the repository and to tag annotations with attributes/keywords so that the annotation repository can be searched on a number of attributes.

5) Making interaction with annotations an effective way of finding new information/viewpoints in a Croquet delivered environment

• Developing a means of automatically categorizing/cataloging annotations
• Developing a means of visualizing the difference/similarity among annotations
• Developing a way by which authors of annotations become notified when other users comment on, or further annotate, objects that the original authors have created.

In doing what's listed above, we'll obviously have to tackle some sticky technical problems. It should be fun and interesting. We hope that this work will also stimulate much thinking, problem solving, and code refinement across the larger development community.

Can You Say Shibboleth?

Many of today's online environments and communities suffer from vulnerability to exploitation by those who seek to use the Internet's intrinsic anonymity to their own selfish advantage. Marketers, spies, and other unscrupulous Internet denizens have forced their way into private communities and email inboxes, disrupting the communities that they find - and sometimes even completely killing them. Those of us who have participated heavily in online communities over the years have lots of experience dealing with the imposters, forgers, and the ever-present anonymous cowards who can disrupt meanigful discourse or reduce it to a very low common denominator. Effective online educational environments must be efficiently insulated from such cruft. Here at UW we're looking into integrating federated identity management with Croquet. By doing so, Croquet users who use their own institutional login/password could access protected resources in Croquet places that are hosted by other institutions. The idea is that educational environments will benefit from people not being able to hide behind masks.

This is where the Shibboleth Project comes in. The project started in the late 1990s by Internet2 as a way of developing an open-source standards-based architecture that provides trusted, inter-institutional access to Web resources. It consists of an institutional Identity Provider component that authenticates users and provides trusted assertions about the user and a resource provider's Service Provider component which validates assertions and makes access control decisions about the user. Generally speaking, when an unidentified user attempts to access services, Shibboleth initiates a handshake between the Service and Identity Providers and allows the Identity Provider to create attribute assertions about the user without the Service Provider needing to keep track of the IDs of all potential users of the system.



Althogh it can get a bit freaky (as the above diagram suggests), this form of federated identity management permits the user's home institution to vouch for a users identity and provide a service provider with only the information necessary for a given session - an important way of protecting personal information, mitigating against identity theft, meeting FERPA and HIPPA requirements etc.. Integrating this now Web based system with Croquet would provide lots of benefits to educational and institutional uses of Croquet. Multiple insititutions (those with attribute repositories such as LDAP) could cooperate in creating restricted access learning environments in which students and educators from those institutions could interact and learn - without the need for each institution to set up an account for all the users of such spaces. A side benefit of this is that Fair Use limitation provisions on copyright laws would allow copyrightable materials to be distributed in such spaces - a feature that's really important to educators (and is probably one of the main reasons that academic institutions employ the use of cumbersome Course Management Systems over plain old websites, blogs, and wikis).



In case you're wondering, the word shibboleth refers to a kind of linguistic password: A way of speaking (a pronunciation, or the use of a particular expression) that identifies one as a member of an 'in' group. The term derives from the biblical story where two Semitic tribes, the Ephraimites and the Gileadites, have a great battle. The Gileadites defeat the Ephraimites, and set up a blockade to catch the fleeing Ephraimites. The sentries asked each person to say the word shibboleth (meaning 'ear of grain' or 'stream' depending on who you talk to). The Ephraimites, who had no sh sound in their language, pronounced the word with an s and were thereby unmasked as the enemy and slaughtered (and perhaps a few lisping Gileadites met their fate this way as well).