Earlier quoted context omitted.
This is where differential synchronization shines (basically git). While OT/CRDT are really good for syncing small edits, they suck at being eventually consistent (with intentions preserved) on very large edits. We make a powerful collaborative word processor for the browser (Zoho Writer https://writer.zoho.com ) with complete offline support. This is one problem we'd like to solve in the long term. One way to solve…
> 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. OTOH, isn't this a rare scenario? How perfect it has to be?How much of a compromise can the users accept? These are interesting questions which shows that creating this kind of software isn't easy -- b…
Open source collaborative text editors
101–110 of 167 posts
Re: Open source collaborative text editors
#102Emacs can connect to multiple screens.
https://www.gnu.org/software/emacs/manual/html_node/emacs/TC...
Re: Open source collaborative text editors
#103Another one missing: https://en.wikipedia.org/wiki/SubEthaEdit SubEthaEdit is a collaborative real-time editor designed for Mac OS X. The name comes from the Sub-Etha communication network in The Hitchhiker's Guide to the Galaxy series. From 2003.
Re: Open source collaborative text editors
#104Earlier quoted context omitted.
You can currently already do good-enough-for-most DOM-level synchronization using any editor, of which we have a few examples. A lot of the examples of RTC out there (apps using TogetherJS for instance) are doing this already. For rich text, we'd like to be able to provide 100% support for a particular editor's capabilities, which necessitates a deeper, custom data model. One of our value propositions is a unified ba…
I am curious about this argument - I think CKEditor 5 made a similar one in this epic blog post about how they implemented real-time collaboration ( https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri... ). We're using Quill.js with ShareDB, which supports JSON structures (which is great, because for us we often have documents with several rich text fields, and other complex structures). So far we've been ab…
I am not sure if I understand you correctly here, but it's not really that. Could you give me a more concrete example?
The kind of problems for extra types are, for example: user A changes a paragraph to a list item and user B splits it. As a result you'd like to have two list items instead of a list item followed by a paragraph. This is impossible if you don't give more semantic meaning to the operations.
There are other problems though, as you mentioned - with invalid document. For example, you have this kind of a list:
* Foo
__* Bar
__* Baz
User A outdents "Bar" and user B indents "Baz" creating a list like this:
* Foo
* Bar
____* Baz
In CKE5 this is an incorrect list (we don't allow indent differences bigger than one). This cannot be fixed through OT so we fix it in post-fixers which are fired after all the changes are applied.
Re: Open source collaborative text editors
#105It's an incredibly fun topic, and one that's also really challenging. It also gave me first-hand experience with fuzz-testing where I could simulate all kinds of concurrent-edit conflicts and ensure both clients came out with the same end-result. While the end client/server implementations are working, it was a lot more effort than I anticipated building a full-fledged editor on top. I was too stubborn at the time to attempt to integrate with existing RTEs though, so the most notable part of the project was the core lib, not the end product.
For those interested in implementing it for themselves, I can't recommend this piece [3] by @djspiewak enough.
[1] https://github.com/jahfer/ot [2] https://github.com/jahfer/othello [3] http://www.codecommit.com/blog/java/understanding-and-applyi...
Re: Open source collaborative text editors
#106What many people not fully grasp, at first sight, is that offline support for a collaborative editor is at least an order of magnitude more complex than just building a collaborative editor. In online collaborative environments, solving conflicts is relatively simple, as the changes are supposed to be small. But when two (or more) people are working on the same document without synching it for hours or days, the merg…
Re: Open source collaborative text editors
#107I’m new to the topic from a technical point of view. I was wondering if the conflict resolving issues are fundamentally different from online gaming scenarios. I.e., could the ways problems are solved in multiplayer games also be applied to collaborative editors and vice versa?
Good question, but it could be responded to by writing a thesis.
Re: Open source collaborative text editors
#108Re: Open source collaborative text editors
#109Re: Open source collaborative text editors
#110I found this recent paper highly enlightening: “Real Differences between OT and CRDT for Co-Editors” – Chengzheng Sun, David Sun, Agustina, Weiwei Cai, October 2018. Arxiv meta: https://arxiv.org/abs/1810.02137 PDF: https://arxiv.org/pdf/1810.02137.pdf It’s well written imo. The conclusions chapter is very good. “In this work, we have critically reviewed and evaluated representative OT and CRDT solutions, with respec…
I don't know how much they differ, though.