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

[Torben Hoffmann]

On Thu, Dec 27, 2012 at 3:18 AM, François Pinard <address@hidden> wrote:

Eric Schulte <address@hidden> 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 :-).

Not sure if it would be speedy enough, but gitit is based on git and since it is a wiki running on top of git with the ability to edit the documents either through a traditional wiki frontend in a browser or as a raw file in an editor of your choice on your own machine.

Inventing a protocol to deal with synchronisation is not trivial, so a good starting point might be gitit or raw git with the intention of learning about what the real issues are before creating a system from scratch to solve what might not be the right problem to solve.

I have not used org enough to be able to judge these issues, but I would like to have a good multi-user solution since org seems to be one of the better ways to collaborate.

<snip>

 

Cheers,

__

 /orben

--
http://www.linkedin.com/in/torbenhoffmann