Wave is neat and I currently think it will be very widely adopted. This note is quick summary of what it appears to be. This is very impressionistic. The specifications are amazingly rough! I’m not sure I’d call this a platform but I’m sure other people will. It certainly creates a large option space for building things. Wave certain mets one of the requirements of a great platform; it opens up so many options for things to do that if you ask “What is it for?” the right answer is: “I don’t know.” Or as a friend of mine once observed: a good platform is about nothing. The demos at Google IO obscure that. That always happens. For example when they first demo’d the Macintosh they had build one or two spectacular application, MacPaint for example. People would look at their demos and think: “Oh so this is a machine for doing drawings.”
Wave provides the tools to do realtime distributed coordination of a complex activity. For example that activity might be a game of checkers, or developing a product plan, a conversation, the distribution of a todo list. So Wave provides tools to solve the coordination problems that arise when you have a data structure distributed around and multiple parties all modifying it. Wave adopts the same technique we use for source control, optimistic concurrency. Everybody edits their local copy. These edits may turn out to conflict with each other. The resulting conflicts are resolved by some mechanism, which in the Wave terminology are given the math like name operational transforms. In source control systems I’ve always called that conflict resolution.
A Wave document is said to consist of a set of wavelets which in turn contain one or more XML documents. For example a Wave document representing a game might have wavelets for all the players, spectators, officials, the score board, game state, the moves, advertising, discussion threads, and individual comments, etc. etc. Nothing in the Wave specification blocks out how all those wavelets manage to relate to each other. Different activities will, of course have different kinds of constitute parts. Nothing I’ve read yet specifies even the building blocks for things like users, bits of HTML text, etc.
But the spec does block out what the primitives are for editing the XML documents that constitute the atomic elements of the Wave. Those operations are a small set of editing operations: move pointer, insert text, insert XML tag, split XML element. It reminds you of using a text editor.
These are the operations which might give rise to conflict. If Alice and Bob are working on the plan for a party and both change the budget for snacks those edits might both be represented by a series of operations (move to char 120, delete 5 characters, insert “25.00”); with Alice entering “25.00” and Bob entering “45.00”. The protocol has a scheme for resolving this conflict. It does not average the two! It just picks one, deterministically, and move on.
That’s about it. But there are some entertaining bits piled on top that are fun, and necessary. I’ll mention three of these: historical background, how this all gets federated, how access rights are managed.
Optimistic concurrency goes back at least into the 1970s, at least that’s the first time I saw it. I think the first time I saw it used to for a realtime application with human users was drawing system out of Parc in the 1990s – and one of Google’s whitepapers on Wave mentions that. These days there are two very nice applications that I’ve used to coordinate activities Subethaedit and Etherpad. I highly recommend Etherpad to anybody who’s working on an agenda or meeting notes jointly with other people – it’s fun.
While it is possible to imagine implementing Wave entirely as a peer to peer system with no central coordination, Subethaedit actually does that. Wave implementors are all going to have a server that labors on behalf of the users participating in the activity the Wave represents by storing the Wave document, and orchestrating the on going edits and naively resolving conflicts as they arise. The plan is to allow a user’s wave server to collaborate with other such servers. That works by having one server act as master for each wavelet. It’s worth noting that every participant in a Wave document is not necessarily a participant in every wavelet of that document. In our example game, two spectators at a game can have a private chat within the game’s Wave document. To be responsive each server caches copies of the wavelets his users are participating in, and to for reasons of thrift and privacy these are limited to just those. The authoritative server is responsible for retaining the master copy of the wavelet and for resolving conflicts. So every edit flows to this master and then back out to the other participating servers. There is a bit of crypto complexity layered on on top of that to assure that that bad actors can’t masquerade as another participant.
It is very unclear at this point how access rights to waves are managed. Obviously wavelets will have participating users. The participation will be asserted along with some rights; for example the right to view but not the right to modify. In addition there will be groups of users, and these too will be asserted as participating in a wavelet. If that’s the case then determining if a user has the right to do something will involve searching the user and group assertions on the wavelet. Remember above that a Wave Document consists of just a set of Wavelets. Obviously for any given kind of Wave Document there will be more structure than just a set. For example our spectators’ private conversation would consist of the conversation and then a thread of comments. It is totally unclear if how access rights are propagated or computed across those structures.
Everything is amazingly raw at this point. Which signals virgin territory. It’s unclear how good a landlord Google will be, but no doubt a lot of people are going to go forth and attempt to stake some claims on this landscape.