While this sounds great, eventual consistency DOES NOT mean semantic consistency. This rules it out for many applications where semantic correctness is important.
Even for simple text documents you can get eventually correct but semantically incorrect results.
For example, consider the sentence
"The car run well"
This has an obvious grammatical error.
Now imagine two collaborative editors.
Editor 1: Fixes this to
"The car runs well"
Editor 2: Fixes this to
"The car will run well"
Depending on the specific ordering of character inserts and deletes this could easily converge to
"The car will runs well"
Obviously this statement is both grammatically incorrect as well as semantically ambiguous. (However, both editors see the same result and it is hence eventually consistent). Worse, OT collaborative editing will silently do this and carry on.
Now, for non-critical text where errors like this are ok, this may not be a big problem. But imagine contracts or white papers, or trying to use this on something like a spreadsheet where semantic correctness is critical and one can see why the current scope of collaborative "real-time" editing is very limited.
In general current "real-time" editing approaches like OT are outright dangerous.
I think OT and other "real-time" collaborative editors are practical if you are willing to (or your use case can) live with "silent semantic errors".
The greater the document "interconnectivity" (eg, paragraph A is semantically related to paragraph C), the greater the likelihood of having far-flung silent semantic errors.
For documents like spreadsheets this is very obvious because you start getting nonsensical results and (hopefully) errors very quickly. For Word-like documents, the errors are "silent" and thus much more insidious.
My point was that that is an element of OT which many users don't realize.
With regards to predictability, I would not call the results of OT predictable from a user's perspective. It is predictable in the narrow sense that for a sequence of arrival of operations AT THE SERVER it is predictable.
However, it is impossible for a user to predict how their local operations will interleave at the server with other users' local operations. For all practical purposes the converged result is unpredictable from the user's perspective.
The only property which one can confidently assert with OT is eventual consistency.
but wouldn't this be somewhat (*not 100%) mitigated with UI? (e.g. showing carret positions + time-agos of different users, asking user(s) to resolve a conflict, etc.)
Asking users to resolve a conflict is not possible, because the whole idea of OT is to have no-conflict merges and would have no idea where the conflicts are.
Some practical solutions are that the document starts out in a 'real-time collaborative editing' phase. After this phase is over, the document moves to a 'review' phase where the document is reviewed for semantic errors and those errors are fixed using a 'non-real-time' approach.
The only way I see at this time to avoid silent semantic errors in the first place are non-real-time approaches.
The best practices here are optimistic locking/leasing of "semantically-connected regions" (could be defined as a paragraph, document, multi-docset, worksheet, slide etc.) along with semantically useful diffs (diffs that are meaningful for an end user) for conflicts.
You could say that this is the approach taken by version control systems like git, where the semantically-connected region is the File/Document.
Semantically useful diffs for anything other than text documents is a non-trivial problem in itself. But is still more tractable than avoiding or detecting silent semantic errors with OT.
Here's the code that simulates all the client/server communication: https://github.com/cricklet/blue-ot.js/blob/master/js/ot/orc...
It shouldn't be too hard to take that and put it in an actual client/server architecture. The client needs to have a way to send local operations to the server (this can just be an endpoint on the server) and the server needs a way to broadcast operations to all clients (probably webRTC?).
Did you see this article? It was posted on HN yesterday. It links to a gh project that might be useful for your project. https://getkey.eu/blog/5862b0cf/webrtc:-the-future-of-web-ga...
> (probably webRTC?). It can also be done with SignalR.
(You could also have cited Etherpad as a common implementation in addition to Docs. Etherpad was a direct predecessor to character by character OT in Docs —the team was acquhired— and it is still widely used by many organizations. But then there is so many examples and libs, I understand that you wanted to just give context!)
I guess my use case is quite unique: [Todo.taskpaper] needs to sync multiple "views" of a single document in the same web app. Right now it uses very naive syncing; I'm going to try to upgrade it to blue-ot.js.
[ShareDB]: https://github.com/share/sharedb
[1]: http://stackoverflow.com/q/40616650/117030
[Todo.taskpaper]: https://todo-taskpaper.leftium.com
