Re: Rudel - Real-Time collaborative editing of Org-Mode files

["François Pinard" <pinard@iro.umontreal.ca>]

Eric Schulte <schulte.eric@gmail.com> writes:

> Unfortunately Rudel doesn't appear to be maintained [...]

Moreover, looking around, I saw a few comparisons and comments in which
other tools using the Obby protocol, which Rudel primarily supports, had
negative light.  I also found out that the synchronization problem and
issues are far, far more complex than I initially thought.  There are
really many avenues, while none seem perfect so far.

> Rather than an Org-mode specific solution, I think adopting Rudel or
> developing something similar which provides emacs-wide support for
> standard collaborative editing protocols (assuming any currently exist)
> would be the best way forward.

Agreed that any nice and general solution which overwhelms [not sure of
that word in English] Org, and even Emacs, should be considered more
tempting.  An full Emacs Lisp solution would be a wrong solution, as the
protocol itself should be implemented without the need of Emacs.  On the
other hand, any solution encumbered with explicit editing minutiae (make
this bold, change font, etc.) is less attractive, because it would mean
spurious and unwanted burden for Org files.

In my wildest dreams :-), I would see real-time collaboration between
people with most participant working on the text of a document, I mean
what follow headers or the header text itself, while a few others
reorganize the structure by moving headers around.  Moving headers
should be nothing more than moving headers, it should not imply deletion
followed by transmission of re-inserted text, as this would seriously
disrupt those altering the text: the re-organization should happen
magically under participant's feet while they are editing, nice and
easy.

Now, the notion of structure may be rendered by a synchronization
mechanism in a way which overwhelms Org by the concept of efficiently
handled nested documents, an single Org file would itself be a
collection of such nested documents.  Just an idea of course, there
might be other avenues as well which are acceptable as long as they
allow structure reorganization without text being transmitted again.

I have the vague, and admittedly strange intuition that Git internals
have the potential for representing nested documents through the
repository structure, for discovering both structural and textual
overhaul, and even for transmitting differences over the wires.  But I
doubt, all efficient that Git may already be, that it would be speedy
enough to be part of a solution.  That might even be elegant, so I hope
I'm wrong on the speed issue :-).

Maybe such a protocol already exists in an efficient or acceptable way,
yet I would tend to doubt it, and it seems like a serious undertaking to
develop one.  It also much depends if we want to accept a solution based
on a central broker for modifications, which is less difficult than a
solution based on modifications flooding over many pairwise connections,
I suspect the latter could yield conflicts and oscillation loops.

Another problem is the initial contact between two widely differing Org
files declared to represent a single one.  I do not like the solution of
having a broker holding the "official" copy of it.  Once a collaboration
session terminates, I would like that no copy be especially official in
a technical sense.  Humans would decide between them which is which!

François