Sorry, what? OT requires centralized servers to do intention resolution. CRDTs are a set of operations that can work on any peer and resolve correctly, without extra coordination or central resolution. The two things are about opposite as they can get. Some CRDTs can be used to make Google Docs style OT, but are not specific to OT use cases. Source: Me, I'm the leading industry and open source expert on CRDTs which p…
Why OT cannot be applied on P2P networks? Does Google Docs use a transformation-based server mean that all OT need a central server?
Real Differences Between OT and CRDT for Co-Editors
11–20 of 66 posts
Re: Real Differences Between OT and CRDT for Co-Editors
#12An article of disappointing quality from well known OT authors. Like,algo x has issue X, algo y has issue Y, z has Z, so CRDT has issues X, Y and Z... and many things like that.
Re: Real Differences Between OT and CRDT for Co-Editors
#13An article of disappointing quality from well known OT authors. Like,algo x has issue X, algo y has issue Y, z has Z, so CRDT has issues X, Y and Z... and many things like that.
I agree. I don't understand why they are attacking CRDTs at all.
Re: Real Differences Between OT and CRDT for Co-Editors
#14My hunch is that because CRDTs are so much easier to grok than OT, engineers are empowered to make use case-specific improvements that aren't reflected in academic literature.
For example, the Logoot/LSEQ CRDTs have issues with concurrent insert interleaving; however, this can be solved by dedicating a bit-space in each ID solely for followup inserts. The "Inconsistent-Position-Integer-Ordering" problem is solved by comparing ids level-by-level instead of in one shot.
Fundamentally, CRDTs have strong strategic advantages over OT. Given a document size N and a document edit history H:
* CRDT size is O(N) where OT is O(H)
* CRDT updates are O(log N) where OT is O(H^2)
In any nontrivial document, H ≫ N. This means CRDTs have much better perf than OT. Additionally, the best CRDTs (like Logoot/LSEQ) don't require tombstones, garbage collection, or "quiescence." The complexity burden is far lower.
To top it off, CRDTs are offline-capable by default.
Re: Real Differences Between OT and CRDT for Co-Editors
#15CRDTs don't require an external causal-order-preserving communication service. That's kind of the whole point of CRDTs. At the same time this is what imposes certain limitations on how they can be used. But so is automatic conflict resolution in collaborative editing.
Re: Real Differences Between OT and CRDT for Co-Editors
#16Here's the key sentence: "concrete implementations of CRDT in co-editors revealed key missing steps in CRDT literature." This paper may be correct for academic CRDTs but it is very wrong when looking at industry implementations. My hunch is that because CRDTs are so much easier to grok than OT, engineers are empowered to make use case-specific improvements that aren't reflected in academic literature. For example, th…
Re: Real Differences Between OT and CRDT for Co-Editors
#17"most other OT solutions ... do not require a central server to do (any part of) the OT work, but only require the use of an external causal-order-preserving communication service (the same as most CRDT solutions). " CRDTs don't require an external causal-order-preserving communication service. That's kind of the whole point of CRDTs. At the same time this is what imposes certain limitations on how they can be used.…
Re: Real Differences Between OT and CRDT for Co-Editors
#18"most other OT solutions ... do not require a central server to do (any part of) the OT work, but only require the use of an external causal-order-preserving communication service (the same as most CRDT solutions). " CRDTs don't require an external causal-order-preserving communication service. That's kind of the whole point of CRDTs. At the same time this is what imposes certain limitations on how they can be used.…
Except for WOOT, which CRDT for co-editor does not require causal ordering?
Re: Real Differences Between OT and CRDT for Co-Editors
#19Only tangentially related, but today I was reading about collaborative editing using Quill.js (a rich text editor) and found a really nice solution based on sharedb (using ottypes/rich-text): https://github.com/pedrosanta/quill-sharedb-cursors Before I dive knee deep into this, does anyone have any opinion on sharedb or better alternatives? (it was listed in this post under it's old name, sharejs, as one of the more…
The article above says sharedb is originally written by a Google Wave developer.
We wrote ShareDB at Lever[1], which was in the 2012 YC batch (iirc). We wrote it to allow realtime collaborative editing in our application of all our data fields by default. I'm still really proud of that work. ShareDB primarily uses JSON-OT[2], which lets you do realtime OT over arbitrary application data. The lever team has been maintaining & improving sharedb for the last few years, which is really lovely to see as I've moved on to other projects.
One nice thing about OT is that its much easier to implement. The original quilljs author (Jason Chen) wrote the rich text OT implementation. ShareDB works with any OT code (so long as operations can be JSON stringified / parsed). And its all hooked up in quill, which is super neat. And looking at the quill github[3], it looks like David Greenspan has been maintaining quill recently. David Greenspan is one of the original authors of Etherpad, which is one of the first web based text OT engines.
Re: Real Differences Between OT and CRDT for Co-Editors
#20Earlier quoted context omitted.
Except for WOOT, which CRDT for co-editor does not require causal ordering?
RON CT/RGA may consume inputs in arbitrary order.