2. HOW MUCH USE CAN THE APPLICATION SUPPORT?
(See part 1.)

The architecture of Croquet is very different from that of, for example, J2EE applications. In a client-server application, one server or server “farm” must process each and every interaction initiated by the thousands or millions of users. The only thing processed on the end-user's computer may be as little as the HTML formatting of the text and image results. Every single other computation must be handled on the big-iron servers. To double the number of users, the capacity of the servers must be doubled. It should be no surprise, then, that so much effort goes into trying to squeeze out each available computing cycle in such architectures.

When an application has state — that is, when results depend on previous results rather than simply generating static files — client-server does MUCH worse. The amount of storage required can go up much faster. In some cases the application state depends on the number of possible connections between users or between applications. The storage (and certain kinds of search-like operations) increases as the square of the number of users or applications (N^2, c.f. Metcalfe's law). But we are particularly interested in allowing students and faculty to form their own ad-hoc groups among which to communicate and solve problems. A client-server architecture hosting such “group forming” applications would grow exponentially to the number of users (2^N, c.f. Reed's 3rd law). With only a few users, this architecture would not work at all, no matter how (finitely) fast the servers, or what language the application is written in. (See Reed's discussion for a surprisingly accessible treatment of value, saturation, and other issues.)
[Read More!]

Croquet is built on some well-used, but not mainstream technologies. A colleague has asked “Why should we believe that Squeak scales to the enterprise?” I'd like to share my answer, to solicit comment.

It is good to ask this, and there are several aspects to the answer:
1. How reliable is the underlying software?
2. How much use can the software support?
3. How will applications be developed?
4. How reliable is the community.

Part 1 of 4.

[Read More!]

Internal problems in Brie. Some nasty, some trivial, all annoying. We'll work 'em out, but time to think of something else for a while. How about huge cultural paradigm shifts?

Clearly, something's going on in the area of intellectual property. The old models are not serving. Everybody's got something to say. (Here and there are some current MIT community examples.) On the one hand, Apple tries to sue companies for using a Windows-Icons-Menus-Pointer (WIMP) look-and-feel that they themselves didn't invent, and they won't let me rip the songs I legally bought from them. On the other hand, they want to use the name “Apple” despite clearly being in competition with Apple Records in the music business, and they produce a variety of devices in the new-cultural rip-mix-and-burn chain. Are they schizo, or is it just opportunistic business? I think it's another data point towards the conclusion that we're waiting for Thomas Kuhn (in a broad sense) to point the new way.

How can we understand intellectual property rights in a digital age? I propose that we try to get at what we really mean in terms of some established axioms.
[Read More!]

My wife is getting frustrated with the medium as she constantly checks for the latest in the raging debate in her favorite mailing-list. Meanwhile, writers and researchers lament the loss of the art and practice of writing letters.

There's no spec for Croquet. Although the architects have mature experience and good taste in evaluating technologies for what does and doesn't work, I don't think they set out to achieve a particular set of characteristics. Yet one of the things that appeals to me about Croquet is the characteristic that it is agnostic about what mode of communication works best: Synchronous like face-to-face conversation and chat, or asynchronous like email or a handwritten letter; Seemingly anonymous like most of the Web and multi-player games, or full of social cues like voice and video communication. Croquet is equally facile at all.(*)

But what works best? When? In what ways? My boss, Julian, has been bringing together a very interesting group of educators and scientists as initial users of a Croquet Collaboratory that we are building. Although they come at it from perspectives that range as far as art, public health, and games, I think they are all vitally interested in this issue. By having a single medium that provides all – a meta-medium – they can study group interactions and observe how different communication techniques affect outcomes.

(*) I'm not quite sure what it says that I'm comfortable saying this, even though the effectiveness of both persistence and naturalistic voice and video have only been suggested in demonstrations, rather than proven in practice. Is it vision, confidence, or faith among the developers, or naiveté and the academic environment?

How do we integrate Croquet with the Web? How do we integrate with legacy applications in general?

We interact with computers now in a document model developed by Alan Kay’s Xerox PARC team a long time ago. (Xerox: The Document Company.) It is as is if we have our head bent over our desktop, looking at a piece of paper. We slide other pieces of paper in and out below the face of our bowed head. In Croquet, Kay’s team today lets us lift our head up off the desk and look up at the world around us, including our coworkers. But just as the 3D world has paper within it, shouldn’t the Croquet world have document-based software within it? Yes!
[Read More!]

I just had one of those damn computer things, where I send an email to someone who I couldn't reach by voice, but just after sending it, I get an email from that person that changes the conditions of what I was writing to the person about. Arghh.

I've written before about how Croquet fosters both synchronous and asynchronous communication, like combining chat and email. Here's how it plays out in this particular scenario. I go to the special space that Alice and I have created (with a few clicks or voice commands) for the stuff common to us. (Or maybe common to a group of three or more. It doesn't matter.) I create a message in that space – voice, text, or video. The idea is that Alice will see that message (and possibly be notified) and will review at her leisure. Alice starts to do the same thing, but since each of us has a presence (an avatar) visible to anyone else in the space, we see each other. Then we just start talking, directly. While we do so, I can even point at the paragraph that I was just composing. Alice can edit it, too, so that she or I can then bring over the collaboratively revised version to Bob. No mail client. No telephone. No chat client. No whiteboard. No filenames or email addresses. No server.

OK, this isn't that different in principle from the little colored balls in Macintosh Mail that tell you which addresses belong to people who are in your buddy list and available for iChat at this moment. But maybe it's enough different to actually be useable.

Inspired by John's observation of a slow news period, I checked the activity of Croquet bloggers. Except for my 9 day old announcement, the average posting is 22 days old.

I guess everyone's hard at work. Come on guys, tell us how it's going!

We are excited to have a new developer joining us on Croquet at U.Wisconsin. Joshua Gargus is moving to Madison all the way from Atlanta, which is quite a big step for such a young man. And he and has wife had just bought a house in Georgia! Both my boss and I have moved our families cross-country for new jobs, including a period where our wives had stayed at the old house, and we know it’s not easy.

Joshua has already clearly dedicated his work to highly interactive applications on the cutting edge of technology. A haptic controller that lets you physically mold “digital clay,” including the ability to pull the molded surface out as well as merely pushing it in. (Think about it.) A sketchbook that recognizes individual strokes (not bitmaps) on a timeline for playback, annotation, and hardware rendering in various styles. Much of his work has been in Squeak, done at the leading centers for Squeak development. (Croquet is built on top of Squeak.)

I’ve looked at some of Joshua’s code, and I’m excited that we’re getting such a talented developer. Coming up: what we’ll both be working on…

My dear friend John, whose generosity and interests drive this site, has said something in comment to this entry, which I just have to call him on:

“The more everything ties together the more we are open for invasion. But the Paris Hiltons of the world seem to embrace the great borgification, the assimilation into the overmind, in which notions such as autonomy and privacy are not so much quaint as incomprehensible.”

Whoa, there buddy! You're going to have to explain why tying stuff together makes it more open to invasion. Ever try to invade a strawberry thicket? There's good design and bad design (with respect to various desirable or undesirable effects), but I see no reason that a good interconnected design is any more pervious then a bunch of isolated stuff. In fact, in my admittedly limited understanding of military and tech. security history, the concepts of "defense in depth" and "divide and conquer" suggest to me that interconnected stuff (if done right) may be inherently safer.

Besides, I’m touchy-feely enough that I just plain like the idea of interconnectedness (done right) being not only safer, but freer and more open and enabling, not more oppressive. Croquet architect David Smith just attended the International Summit on Democracy, Terrorism and Security in Madrid. They have produced a document that begins to articulate how I happen to feel. It is called The Infrastructure of Democracy.

I had a conversation with someone at the University here about architecting Croquet – or a class of Croquet applications - so that the infrastructure can be centrally controlled. By the University, by a consortium of universities or what have you. “This is wrong,” I thought. If you design it so that the whole thing – the very infrastructure -- can be controlled by you, then it will be controlled, but not by you. Either Croquet will be a success or it won’t, and if it is a success, then the Elephant in the Hallway, Microsoft, will come along and control their version. Or some government, or terrorists, or whatever bad guys haunt your anxiety closet.

I’ve recently learned from some folks in the tech security community that security is weakened when you rely on prohibiting that which you cannot prevent. Systems fail, so design your system to fail gracefully. Connectivity is abused, so design your systems to respond to it. Openness and interconnectivity are powerful tools for dealing with the attacks we cannot prevent.

Duke and other schools are giving iPods to students. This site explains that they are looking for innovative ways to introduce technology in education. Poems and lit. to go. School fight songs. Info on the frosh dorms. I think that's great. Why be so focused on visual information? It's interesting to me that cell phone surfing seems to be done on phones outfitted with tiny visual screens and abuses of keyboards. Why not aural displays and voice interfaces? (Although I'm not too keen on the image of zombie students walking around in their own little isolation enforced by earplugs piping in the university's message.)

Duke doesn't mention anything about file sharing, but I wonder how much of their IT push is also meant to get them off the hook that some universities have been placed on in order to try to force them to be responsible for the file-sharing actions of their students.