<%image(20070925-halo3.jpg|500|332|John Harvard as Halo's Master Chief)%>In another sign of the significance of virtual reality, MIT hackers transformed the Harvard benefactor into a character from the popular video game.
How do you coordinate activity across a network? People are doing this all the time, with varying degrees of success. But how is it supposed to work? What is the model to be followed? When I graduated mid-eighties, “Distributed Systems” was still a graduate specialty subject, not a pervasive guiding principle. Today, people like myself don’t seem to have a common ontology of approaches. Well, it’s about time.
I wanted to tell you a wonderful short story I had heard.
Listen to this woman – clearly from within a couple hundred miles of that region between Cologne and Katmandu. She’ll tell you a tale pulled from the darkest depths of her distant memory. You’ll learn something about how all of us perceive things.
We’ve talked about allowing objects to come out of the application in which they have been embedded, and how that removes the lines between applications, operating systems, content, program, etc. and also between user and developer. And the University of Minnesota has been doing some neet work with software robots. I think this is pretty much where it’s all headed. Pleasant dreams, John!
When I wrote “Touchability,” it had already been a while since a buddy had shown me a haptic mouse he was working on. For example, you could feel an actual bump when the mouse enters and leaves an object (a real version of what developers sometimes call rollover). Force feedback was such an obviously good thing that I didn’t even mention then the cool stuff that’s now happening in this area.
As much as I think physical touchability is good, I want to be clear that I want to make Croquet applications be emotionally touchable, too. I want to capture what it is that makes things seem (be?) real. Even without physical force feedback, it should still be fun to fondle stuff because of active visual and aural responses and good 3D design.
When Croquet is a success, what will it be? Really? Forget about the applications, what will Croquet itself actually do?
The other day I was sitting on my back porch. Resting comfortably on my lap was all the resources I needed to do my high-tech computer work. The box also played my favorite music, and when my wife asked about the lyrics, I was able to look them up in the greatest library the world has ever known. We checked our calendar, and printed a custom map to the next day’s event. And so forth.
Not so very long ago, it would have been very hard to imagine this, despite having had it all spelled out for us by Vannevar Bush or by Douglas Englebart on specific dates in 1945 and 1968. For any given technology, it seems to be very hard for most of us to fully imagine our future with it. I think the reason for this is that when the future comes, it’s all about the applications. The music player. The information index and specific song lyric libraries. Calendars, directions, and the tools for my work. We live in applications. We buy applications. Applications make or break a technology. But these applications don’t just happen because they are good ideas. They happen only (and not always) when there is a suitable enabling technology. It is rare that we think about what the enabling technology really is, fundamentally.
My oldest daughter (age 13) just “independently” invented Croquet. Or more specifically, she’s reinvented the underlying computation model called TeaTime. She’s been playing a computer game called “Sims”, in which a single player can create a simulated world, populated with characters that she has configured. These character interact with each other based on their “personalities.”
The version of Sims she uses is not collaborative: each game is independent of anyone else playing the game. But my daughter has a friend (born within a few hours of her, from two parents that lived in the same dorm as my wife and I). Her friend also has Sims, and being 13 year old girls, they play their own games while they talk on the phone with each other. “Let’s make a character called ‘Howard.” Let’s have him do such-and-such. Let’s do this. Let’s do that.“
They’re each using the telephone to coordinate the ”commands” to their respective simulations. Then the games play, producing the same results, even though the game isn’t designed to be networked. That’s exactly how Croquet works.
Now, there are other issues in the Sims, and these girls are as interested in the differences as in keeping things in synch. Pretty cool.
None of the previous matters if the software isn’t useful, or if we are not allowed to use the software. The former is what we’re working on, but the latter is a very complex issue. Croquet is certainly not at critical mass. It could certainly go away. However, we feel it is immune at least from licensing plays such as those that have plagued the use of proprietary systems in higher ed, or those that have fractured the Java community. As the number of users in such systems grows, attempts for controlling proprietary lock-in have been very expensive. Croquet fights this in several ways: with an open source license in which all work on Croquet itself is available to anyone; with a P2P architecture that eliminates any advantage to “controlling the servers”; and with a dynamic language that eliminates any advantage to “controlling the release.” We feel that this last will be further strengthened by upcoming work in architecture and security, to be carried out here at UW. For the general health of the community, I look forward to upcoming announcements.
3. HOW WILL APPLICATIONS BE DEVELOPED?
(See part 1.)
It is not practical to expect users to develop applications in Squeak. There is too much to learn. But neither is it practical to expect users to develop applications in Java or ANY OTHER COMPUTER LANGUAGE. There is no way that any community of professional developers could possibly keep up with the demand that we hope for unique applications. No matter what language they used, nor even how many developers were available. There’s simply many more users — and user needs — than there are developers. As with scalability of load, we need another approach. The answer is the same: push the load to the edge of the network.