From: "François Pinard" <pinard@iro.umontreal.ca>
To: emacs-orgmode@gnu.org
Subject: Re: Rudel - Real-Time collaborative editing of Org-Mode files
Date: Wed, 26 Dec 2012 21:18:30 -0500 [thread overview]
Message-ID: <86r4mcz18p.fsf@iro.umontreal.ca> (raw)
In-Reply-To: <87k3s4ij3m.fsf@gmail.com> (Eric Schulte's message of "Wed, 26 Dec 2012 14:44:45 -0700")
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
next prev parent reply other threads:[~2012-12-27 2:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 18:50 Rudel - Real-Time collaborative editing of Org-Mode files Ciaran Mulloy
2012-12-23 23:18 ` Bastien
2012-12-25 13:22 ` François Pinard
2012-12-25 20:02 ` François Pinard
2012-12-26 21:44 ` Eric Schulte
2012-12-27 2:18 ` François Pinard [this message]
2013-01-01 22:04 ` Torben Hoffmann
2013-01-12 14:47 ` François Pinard
2013-01-12 23:33 ` colorg: Protocol [was: Re: Rudel - Real-Time collaborative editing of Org-Mode files] François Pinard
2013-01-14 10:29 ` Samuel Loury
2013-01-14 14:38 ` François Pinard
2013-04-01 20:46 ` Torben Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86r4mcz18p.fsf@iro.umontreal.ca \
--to=pinard@iro.umontreal.ca \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).