
Operational Transformation (algorithm behind Wave, Google Docs) - samstokes
http://www.codecommit.com/blog/java/understanding-and-applying-operational-transformation?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+codecommit+%28Code+Commit%29
======
jerf
I worked out the logic for a system like this for one of those "Someday I'd
like to release this" projects. The way I looked at it is that basically it's
just patch theory. It's the same problem you get with a source-control system,
it's just happening faster. You can use the exact same patch theory.

In fact I think patch theory may even be stronger than the algorithms
described here. This link says "we need to impose a restriction on the client:
we can never send more than one operation at a time to the server.", but patch
theory can handle that case just fine and still "recover" later. The only
thing you need is some sort of merge policy, and my plan was just to
arbitrarily (but consistently) pick a side, because unlike a code merge where
you could literally have kilobytes of conflict and discarding either side
could be bad, in the collaborative case you're looking at a few small
commands. (Even a large copy/paste is just one operation, from the human
perspective. No matter how collaborative your editor, two people editing the
same character is always going to be a problem; there's really no point trying
to get too clever.)

If you are interested in this topic, you might want to read
[http://en.wikibooks.org/wiki/Understanding_darcs/Patch_theor...](http://en.wikibooks.org/wiki/Understanding_darcs/Patch_theory)
as well. I think patch theory may be stronger than what was described because
it can use patch inverses to do a few things I'm not sure operational
transformation" can, and coming up with inverses for the collaborative editing
case is quite trivial. Note that darcs had a well-known exponential case, I
think in the collaborative editor case it could never come up as everybody is
always within a few seconds of "HEAD".

(Incidentally, the patch approach would also potentially allow offline
interaction as well, though then you can't ignore the merge issue quite so
thoroughly and you could conceivably have exponential merges again, never got
far enough to tell. Sounds like this approach would not allow that. Does Wave
allow offline interaction which it then propagates up? If so then it may be
using something more like patch theory.)

~~~
Rauchg
OT is not patch theory. Google already had a patch-based approach (currently
used in Bespin): <http://code.google.com/p/google-mobwrite/>, which was
replaced with OT. No diffing algorithms are used, even for producing the
operations (which is probably why they're not using `contenteditable`)

Wave does allow offline interaction, and their OT algorithm is optimized for
speed (for example, for the execution of possibly hundreds of buffered
operations). The tradeoff is the requirement for an acknowledgement from the
server after sending each operation or batch of operations.

I'm currently working on an OT implementation that doesn't require ACKs from
the server in my spare time, and relies on a vector clock as opposed to a
single timestamp. It has higher CPU processing power needs, which is why
Wave's algorithm is also more suited to mobile devices[1]

[1] <http://portal.acm.org/citation.cfm?id=1718949> I believe one of the
people involved in this paper is also involved in Wave's OT implementation
paper.

~~~
gritzko
Patch-based stuff is simply based on obsolete 30 yrs old assumptions. Why
should you need a combinatorial algorithm to detect changes if you can track
every user's action? etc etc

OT is a dead end. The problems they struggle with could be trivially
bruteforced by employing unique symbol identifiers.
<http://bouillon.math.usu.ru/articles/ctre.pdf>

~~~
Rauchg
Didn't read the entire paper, but the criticism on Google Wave is poor,
baseless and subjective.

"The authors even had to enrich XML with additional entities named
“annotations” to make it suitable for their needs"

This is what Etherpad did for adding support for lists, bold, italics, etc.
Did anyone complain? Does it not work?

Granted, Wave's approach is way more ambitious. They support any sort of XML
groves, and not just simple 1-level deep tags like Etherpad.

~~~
gritzko
Some unexpected issues are not solved for past 20 years.

I do not attack annotations or XML per se. The general approach "neither thing
is precisely OK, so let's use both" seems questionable to me. I believe, XML
is complex enough, so why do we need XXML? Finally, by using annotations they
recognize that XML nesting is a pain in the ass, but they did not solve the
problem, just sort of relieved it.

Actually, I doubt a lot, whether XML is actually carrying some useful load in
the Wave. But the last one is just a feeling.

~~~
Rauchg
Have you taken a look at admissibility-based transformations (ABT) [1]?

It seems to solve the issues that concern you (validating the correctness of
OT).

[1] <http://portal.acm.org/citation.cfm?id=1713726>

------
gritzko
The present OT is very much an epicycle theory. They always have that one last
issue to fix. In fact, several, if not the most of, classic OT papers were
later found to be inconsistent, e.g. some combination of concurrent edits
makes copies diverge (source: P. Molli). And that problems are extremely hard
to find/understand. Apparently, the original authors of OT had a local network
in mind: universal connectivity, instant message propagation, etc. But the
internet is full of "relativistic" effects: different clients have different
views of the state, messages propagate with finite/varying speed, etc etc.
After reading the article, try to estimate what happens if e.g. one client
syncs hourly/daily/monthly (like in the git), or suppose we don't have a
central server (like in git), or if the stream of edits is too dense... like
we really have a hundred of monkeys... Maybe Google engineers managed to get
the probability of OT screw-ups lower than the probability of all other screw-
ups... but that does not make the theory any better.

(...and the way they dealt with XML is a very special song. OT is pretty much
a complexity explosion itself, but they also multiplied it by the complexity
of XML; got 15 kinds of mutation operations and all the stuff. The fact they
invented "annotations" to skip XML nesting speaks for itself.)

Conclusion. OT is a big messy mess.

------
adrenalin
Hey thanks, have a school-project in progress (a google wave like project)
that need OT, this article will help.

------
saikat
For people interested in the approaches to real-time collab, I made a summary
writeup of what I researched a while back -
[http://techblog.gomockingbird.com/using-real-time-
collaborat...](http://techblog.gomockingbird.com/using-real-time-
collaboration-to-help-solve-r) . Still hoping to actually dive into all the
algorithms later, but there is definitely a lot out there, just mostly in the
form of academic papers.

------
mvaerle
Make sure you watch this guy: <http://www.youtube.com/watch?v=84zqbXUQIHc>
(presentation at google).

They developed a lot of systems using OT, even going so far as doing
collaborative autocad. There are papers on that if you search for CoMaya and
CoAutoCAD. The complexity, especially of the last one, is mind boggling
though.

------
billjings
"...in light of the fact that Google’s documentation on the subject is sparing
at best, I thought I would take some time to clarify this critical piece of
the puzzle."

Is Google's documentation crap?

~~~
hammerdr
Just very broad: a series of white papers and a sample Java implementation
which doesn't have any persistent storage.

There is certainly space for someone to document the specifics of the Wave
Protocol (and, along with that, operational transforms) and this blog post
goes a long way toward that.

Edit: I should also note that the OT white paper, like most white papers,
builds on prior knowledge and expects some background in the area of research.
You have to read a few white papers in order to really grok it.

~~~
Jd
There was a long blog series on OT not long after the Google Wave that is
linked from the Wave docs:

[http://blog.wavenz.com/2009/07/introduction-to-
operational.h...](http://blog.wavenz.com/2009/07/introduction-to-
operational.html) [http://blog.wavenz.com/2009/07/operational-transformation-
al...](http://blog.wavenz.com/2009/07/operational-transformation-
algorithm.html) [http://blog.wavenz.com/2009/07/operational-transformation-
an...](http://blog.wavenz.com/2009/07/operational-transformation-and.html)

(full disclosure: I helped edit these)

