While I've only skimmed the available protocol draft and whitepapers, I do have a couple thoughts about wave.
Firstly, I can imagine something like this supplanting not just email and instant messaging, but also web forums, blog comments, mailing lists, wikis, bug tracking systems, twitter, and probably various other forms of communication. (But not, apparently, version control systems.) While one might have an attachment to a few of those things, I think most of us would be glad to see most of them collectively die (especially twitter and web forums of course) and be replaced by a data-driven standard, with multiple clients, rather than their general ad-hoc, server-side generated nastiness. (The Project Xanadu guys would be probably be proud.)
Secondly, while Google are making all the right noises about open protocols, multiple providers, etc, and probably only plan to lock in about five nines percent of users to wave.google.com before competing implementations arrive, wave is not a fully distributed system. Spec says:
The operational transform used for concurrency control in wave is [currently] based on mutation of a shared object owned by a central master.
The wave server where the wave is created (IE that has the first operation) is considered the authoritative source of operations for that wave.
If the master server goes away, it sounds like a wave will become frozen and uneditable. There seems to be no way to change the master server after a wave is created, without ending up with an entirely different wave.
(Update: The demo, around minute 70, seems to show a private modification to a wave being made on another server -- so I may be missing a piece of the puzzle.)
The concurrency control protocol will be distributed at some point in the future
How many centralized systems have been successfully converted into distributed systems?
In a similar vein, after reading this whitepaper, I'm left unsure about whether it will be possible to respond to (edit) a wave while offline. Maybe, as clients can cache changes, but how well will conflict resolution work? It seems it would have to be done in the client, and there are some disturbing references here to clients throwing their local state away if they get out of sync with the server.
Hello,
The current specification refers to operational transforms as a way of concurrency control to be used. They seem to have taken some care to make sure the operation set they define can in fact be merged, but I didn't study it enough to be able to tell how many conflict cases there are or how they are supposed to be resolved.
Reading the underlying description on Wikipedia, it looks like equivalent of the Darcs "Patch algebra" and Darcs is fully distributed. However, I didn't read the current wave spec in enough detail to know, whether they really took care of all possible conflicts.
There is a restriction, where client has to wait for the server to process a batch of changes before sending next batch, which seems to be a way to limit the number of transformations server may need to consider and push most of the merging on the client.
As for offline changes, I believe they are easily possible. The client has to cache the operations locally, than after connecting request the operations made meanwhile on the server -- the wavelet seems to always be described as a series of changes -- and just merge it's changes to the current state. That should always be possible if the operational transforms are implemented correctly. And that's in fact only the hard part, modifying existing wavelet -- I expect simply adding a new wavelet (which corresponds to sending new message/comment) to be much more common.
I guess removing the ownership requirement or defining a way to transfer it is left a challenge for anybody who comes up with a workable idea. After all it's a draft and they claim they welcome contributions.
Removing the ownership would require: * Identifying the operations by some unique ids that don't need to be sequential, and * implementing the full operational transformation algorithm for the case where servers become disconnected (the problem is, that it's not possible to tell whether the master server is dead permanently, temporarily or just the network is down).
I think they don't want to implement it because of the complexity involved. Since it seems possible in principle, the "will be distributed in some point in future" might actually be justified.
Note though, that even if both wave and wavelet are only editable as long as the originating server is alive, it's no worse than any current system, because email cannot be edited and mailing lists, forums, wikis and blogs are all tied to the server they run on. If it's possible to add wavelets to a wave without it's originating server (which coould be easily possible -- wavelets don't use sequential ids -- discovery would be an issue than, though), it'd be better than anything except distributed version control and probably sufficient for most purposes.
-- Jan Hudec
I hope that google's modified version of OT handles concurrency as well as you suggest. :-) (I think you're probably right about adding wavelets not tending to conflict, but editing the first wavelet in a wave seems to be common in wave also.)
Not entirely true, for example, I've written a wiki and blog that can be mirrored, cloned, and branched amoung different servers.
Less esoterically, consider email. If Bob CCs Alice and me, and then his server goes down, we can continue to use email to discuss that thread without the experience degrading. If Bob had waved us, we would have to start a new wave if his server went down.
BTW, I'm very curious how wave deals with security. Specifically, it allows users to add arbitrary html/css/javascript to a wave, and then allows the wave to be embedded on a site. How do they avoid cross-site-scripting and all the wealth of other attacks that would seem to open up, I wonder?
Perhaps they use Caja?
I think that you make an important point that distributed-ness is the key to whether "the wave" will spread beyond Google's own wave.
It seems to me that there would need to be clients that are similar to servers as far as the protocol is concerned. For example, e-mail clients frequently manage to speak SMTP, IMAP etc. Similarly, most DVCS clients (like "git") can also act as servers.
If so one could imagine an small client ("estuary"?) that can pull in the waves that are of interest and that are accessible (security models will be interesting) and then proceed to interact with those. The server portion of such a client would differ from a full-blown wave server mainly in scale.
I have yet to read the protocol documentation ( :-( ) so I am not sure whether it can function this way.