I read both parts. Well written, I agree with a lot of stuff. I am long-time CKEditor dev, I was responsible for implementing real-time collaboration in the editor and the OT implementation. Regarding the first part of…
> Operational Transformation (OT) is one of those algorithms, which have been evolving over time, as versions of it have been proven incorrect. Source or explanation required. Also, this:…
> OT is very simple to implement, but needs a server (...) Well, OT in general does not need the server but server-less implementations are more complex (more transforming functions to write, except of "inclusion…
What do you mean by "not fully collaborative"? Both presented solutions seems like quite collaborative.
BTW. there's also a more fresh paper from the same authors: https://arxiv.org/abs/1905.01302 I don't know how much they differ, though.
We frequently joke in our company that we'd love to write a thesis on OT and get a better academical grade ;).
> (...) if two keys depend on each other, and one user sets one key, and the other user sets another key, and the document is now invalid, you'd need the engine to be able to reconcile at a higher level? I am not sure…
So, what is your conclusion after reading it?
Author of the linked blog post here. The example cases for additional types / custom implementation are in this section: https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri... These content-preservation edge…
I don't like "merge" word because it implies how the problem is solved. "Synchronise" would be better, as there is no merging, actually. We use Operational Transformation, so all the changes are stored as operations…
> One way to solve this is to fallback to differential sync when syncing huge offline edits This is another question -- does automatic syncing make sense for huge differences in users' contents? The answer might be no.…
I still need to read that one, though it looks interesting (yes, I only got through the introduction and summary :)). Let's keep in mind that the authors already wrote several papers on OT (also ones that we based CKE5…
This is an interesting subject, to be honest. Of course, it depends on the collaborative editing solution. When it comes to OT -- if the implementation is correct, it doesn't really matter how many operations are queued…
Congratulations on providing a serverless solution. How do you think CRDT would fare in a tree-structured data model? We went with OT and server architecture because it seemed more reliable. You can read more about our…
Oh, don't get me started on modifications we needed to do to make undo look reasonable ... :) At first, we thought that undo is the same thing as collaboration but... nope. The crucial difference is that with undo you…
Graveyard is just another root, like the main one. So, the same way that all elements have the same position in the main root for all clients, elements in graveyard also have the same position for all clients. Thus,…
As far as I remember shareJS was available when we started to work on tree-based OT. We researched it but it turned out to be too simple for what we wanted to achieve and there was no special handling for some edge…
Hi! Certainly, there are different use cases and different expectations. What we call "offline collaboration" can be seen as a special case of the real-time collaboration. In "offline collaboration" you also need to…
Our first idea was to have four basic operations (insert, move, attribute, remove) and then have “deltas” (wrap delta, unwrap delta, merge delta, split delta) which were built using those operations and for which we…
It truly is the most interesting subject I've been working on yet. The fascinating thing about it is that it isn't a "solved" issue with one, correct solution, so you can feel like a 19th-century scientist at times :).
Interesting question! Actually, at the moment we don’t :). We did some testing to see how big this issue is and it turned out that it's not dramatic. The main difficulty with graveyard purging is that you need to keep…
It seems that the link is fine. Scroll a little down and you can test the collaboration in Letters (built using CKE5) or with CKE5 document build (switch the tab).
Using diffs was our very first approach. It was quite naive (not to say dumb) solution but we also came to a conclusion that it will be problematic for tree-structured data and there were also performance issues (for…
Here's the link to the paper discussing tree-based CRDT: https://arxiv.org/abs/1201.1784. I personally find those papers very interesting!
The idea behind storing and loading the data is, in short, this: HTML is the most popular format and it is the default when it comes to publishing web content. Most people want HTML data. However, it is understood that…
I read both parts. Well written, I agree with a lot of stuff. I am long-time CKEditor dev, I was responsible for implementing real-time collaboration in the editor and the OT implementation. Regarding the first part of…
> Operational Transformation (OT) is one of those algorithms, which have been evolving over time, as versions of it have been proven incorrect. Source or explanation required. Also, this:…
> OT is very simple to implement, but needs a server (...) Well, OT in general does not need the server but server-less implementations are more complex (more transforming functions to write, except of "inclusion…
What do you mean by "not fully collaborative"? Both presented solutions seems like quite collaborative.
BTW. there's also a more fresh paper from the same authors: https://arxiv.org/abs/1905.01302 I don't know how much they differ, though.
We frequently joke in our company that we'd love to write a thesis on OT and get a better academical grade ;).
> (...) if two keys depend on each other, and one user sets one key, and the other user sets another key, and the document is now invalid, you'd need the engine to be able to reconcile at a higher level? I am not sure…
So, what is your conclusion after reading it?
Author of the linked blog post here. The example cases for additional types / custom implementation are in this section: https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri... These content-preservation edge…
I don't like "merge" word because it implies how the problem is solved. "Synchronise" would be better, as there is no merging, actually. We use Operational Transformation, so all the changes are stored as operations…
> One way to solve this is to fallback to differential sync when syncing huge offline edits This is another question -- does automatic syncing make sense for huge differences in users' contents? The answer might be no.…
I still need to read that one, though it looks interesting (yes, I only got through the introduction and summary :)). Let's keep in mind that the authors already wrote several papers on OT (also ones that we based CKE5…
This is an interesting subject, to be honest. Of course, it depends on the collaborative editing solution. When it comes to OT -- if the implementation is correct, it doesn't really matter how many operations are queued…
Congratulations on providing a serverless solution. How do you think CRDT would fare in a tree-structured data model? We went with OT and server architecture because it seemed more reliable. You can read more about our…
Oh, don't get me started on modifications we needed to do to make undo look reasonable ... :) At first, we thought that undo is the same thing as collaboration but... nope. The crucial difference is that with undo you…
Graveyard is just another root, like the main one. So, the same way that all elements have the same position in the main root for all clients, elements in graveyard also have the same position for all clients. Thus,…
As far as I remember shareJS was available when we started to work on tree-based OT. We researched it but it turned out to be too simple for what we wanted to achieve and there was no special handling for some edge…
Hi! Certainly, there are different use cases and different expectations. What we call "offline collaboration" can be seen as a special case of the real-time collaboration. In "offline collaboration" you also need to…
Our first idea was to have four basic operations (insert, move, attribute, remove) and then have “deltas” (wrap delta, unwrap delta, merge delta, split delta) which were built using those operations and for which we…
It truly is the most interesting subject I've been working on yet. The fascinating thing about it is that it isn't a "solved" issue with one, correct solution, so you can feel like a 19th-century scientist at times :).
Interesting question! Actually, at the moment we don’t :). We did some testing to see how big this issue is and it turned out that it's not dramatic. The main difficulty with graveyard purging is that you need to keep…
It seems that the link is fine. Scroll a little down and you can test the collaboration in Letters (built using CKE5) or with CKE5 document build (switch the tab).
Using diffs was our very first approach. It was quite naive (not to say dumb) solution but we also came to a conclusion that it will be problematic for tree-structured data and there were also performance issues (for…
Here's the link to the paper discussing tree-based CRDT: https://arxiv.org/abs/1201.1784. I personally find those papers very interesting!
The idea behind storing and loading the data is, in short, this: HTML is the most popular format and it is the default when it comes to publishing web content. Most people want HTML data. However, it is understood that…