1 May 2009
The intended use case for MobWrite is real-time multi-user collaboration. Alice and Bob need to work on the same content at the same time, so they use MobWrite to resolve the conflicts. This use case is fairly obvious and self-explanatory.
Somewhat to my surprise, MobWrite is catching on as a solution for a completely different use case: self-collisions. Consider the following workflow.
The result of this workflow is that Alice has forked her document. Neither her desktop nor her laptop has the latest version of the document. She has collided with herself and is now in the position of having to do a manual three-way merge. This is an inherent danger of any application which uses network storage -- even if there is only a single user.
Users of one such internal application here at Google encountered this self-collision scenario with such regularity that version numbers were added so that only the latest branch could save. This hacky fix just made things worse, one employee was forced to drive home to fetch his open laptop so that he could regain control of the session.
A better solution is to bolt a MobWrite conduit onto the side of the application. All open clients can then synchronize with each other through MobWrite. In the above example, the "Dear" which Alice typed on her laptop would have quietly appeared on her desktop computer shortly after she typed it. The final result would have been "Dear John Smith" on both computers.
The bad news is that as applications move onto the cloud, engineers need to pay more attention to self-collisions. The good news is that if one deals with self-collisions properly, one has laid the groundwork for real-time multi-user collaboration.
Update: Innovation aus Zapfendorf. Is it wrong for a Google employee to participate in a little Googlebombing?