Re:OT and CRDT trade-offs for Real-Time collaboration
by jiofih on Tuesday January 14, 2020 @03:19AM
(#22042839)
But the article is arguing in favor of OT, not CRDT. A couple examples of those edge cases would go a long way, the one given is not very helpful to make a point.
Re:OT and CRDT trade-offs for Real-Time collaboration
by Vinnl on Tuesday January 14, 2020 @03:39AM
(#22042924)
What's wrong with the one given? If my cursor moves because some other user makes some other text bold, that doesn't sound like a desirable experience?
Re:OT and CRDT trade-offs for Real-Time collaboration
by jiofih on Tuesday January 14, 2020 @06:31AM
(#22043818)
Because it doesn’t highlight a particularly relevant deficiency of the CRDT protocol. Preserving cursor position is not hard in that case. The post even mentions stronger downsides of OT, the example does not support the conclusion. Why is OT better?
Re:OT and CRDT trade-offs for Real-Time collaboration
by Vinnl on Tuesday January 14, 2020 @06:57AM
(#22043958)
Huh, the article gave me the impression that preserving the position was a crucial problem there.
As for the last question, I think the later posts will get to that.
Re:OT and CRDT trade-offs for Real-Time collaboration
by eudoxus on Tuesday January 14, 2020 @07:34AM
(#22044187)
Preserving the position of the cursor is a crucial feature for collab editors. However, he doesnt go into detail explaining why CRDTs make this feature impossible. Sure the CRDT route splits the text, but I fail to see why that makes cursor pos preservation impossible?
Re:OT and CRDT trade-offs for Real-Time collaboration
by spyder81 on Tuesday January 14, 2020 @08:17PM
(#22050918)
It's not impossible, particularly in cases where the model is fairly flat.
In complex models it is symptomatic of a larger issue with complexity in CRDTs; the post was already quite long and I didn't want to repeat any more of the research I'd linked to.
Re:OT and CRDT trade-offs for Real-Time collaboration
by jiofih on Wednesday January 15, 2020 @02:59AM
(#22052457)
You mention that example as a turning point for choosing OT, confirming your research. But to an outsider it is not particularly convincing. Especially since you’d expect a CRDT implementation to use the rope/tombstone structure, applying the transform to that sequence of characters and not actually have to split a text node, which looks like a limitation of this particular implementation, or tight coupling between the data model and the DOM.
The post is a good introduction to OT and CRDT, but is very light on actual trade-offs and seems to end with a gut-feeling conclusion, when the title promised “trade-offs between”.
Re:OT and CRDT trade-offs for Real-Time collaboration
by spyder81 on Wednesday January 15, 2020 @04:38PM
(#22058981)
It's hard to offer more detail than that in a blog post. I'm not going to repeat the research papers or write one of my own. The post is already so long and complex, covering so many surface details, I couldn't reasonably push it any further.
Re:OT and CRDT trade-offs for Real-Time collaboration
by jiofih on Thursday January 16, 2020 @02:42AM
(#22062410)
I’d suggest skipping right to the meat of the subject (pros/cons in this case), assuming some previous knowledge, if that’s what the article proposes to share, and simply point readers to learning resources; it’s not possible to start from scratch on every topic. The deeper the subject, the more glaring this problem becomes.
> In OT, every user action is broken down into one or more operations. These operations are transmitted between clients along with their baseline reference; if two users perform actions at the same time, incoming operations must be transformed to include the local operations that have happened since that baseline. They are then applied locally and form the new baseline.
> This constant transformation of operations turned out to have too many edge cases where clients were found to not produce the same baseline (the "wrong" papers above). When that happens, the clients will never converge on the same result and break the fundamental assumption of collaboration.
And that’s exactly right. It’s fairly easy to have an OT system that is very vulnerable, because clients can cheaply generate change sets that are extremely computationally expensive on the server side. I’ve seen a system where a single mobile phone could, in a few seconds, lock up the synchronisation server for days.