From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torben Hoffmann Subject: Re: Rudel - Real-Time collaborative editing of Org-Mode files Date: Tue, 1 Jan 2013 23:04:31 +0100 Message-ID: References: <50D4AF62.2020401@gmail.com> <87txrcxq14.fsf@bzg.ath.cx> <86licmclle.fsf@iro.umontreal.ca> <86han9dho5.fsf@iro.umontreal.ca> <87k3s4ij3m.fsf@gmail.com> <86r4mcz18p.fsf@iro.umontreal.ca> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf3033466774eef604d2415098 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:39841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tq9wp-0002yo-EU for emacs-orgmode@gnu.org; Tue, 01 Jan 2013 17:04:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tq9wm-0007fk-AF for emacs-orgmode@gnu.org; Tue, 01 Jan 2013 17:04:35 -0500 Received: from mail-qc0-f172.google.com ([209.85.216.172]:44564) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tq9wm-0007fg-5B for emacs-orgmode@gnu.org; Tue, 01 Jan 2013 17:04:32 -0500 Received: by mail-qc0-f172.google.com with SMTP id b25so7036356qca.3 for ; Tue, 01 Jan 2013 14:04:31 -0800 (PST) In-Reply-To: <86r4mcz18p.fsf@iro.umontreal.ca> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= Cc: emacs-orgmode@gnu.org --20cf3033466774eef604d2415098 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 27, 2012 at 3:18 AM, Fran=E7ois Pinard wrote: > Eric Schulte 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. Cheers, __ /orben --=20 http://www.linkedin.com/in/torbenhoffmann --20cf3033466774eef604d2415098 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 27, 2012 at 3:18 AM, Fran=E7ois Pinard <pinard@i= ro.umontreal.ca> wrote:
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. =A0I also found out that the synchronization problem and issues are far, far more complex than I initially thought. =A0There 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. =A0An full Emacs Lisp solution would be a wrong solution, as the<= br> protocol itself should be implemented without the need of Emacs. =A0On the<= br> 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. =A0Moving 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. =A0Just 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. =A0But I doubt, all efficient that Git may already be, that it would be speedy
enough to be part of a solution. =A0That 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 s= ince it is a wiki running on top of git with the ability to edit the docume= nts either through a traditional wiki frontend in a browser or as a raw fil= e in an editor of your choice on your own machine.

Inventing a protocol to deal with synchroni= sation is not trivial, so a good starting point might be gitit or raw git w= ith the intention of learning about what the real issues are before creatin= g a system from scratch to solve what might not be the right problem to sol= ve.

I have not used org enough to be able to ju= dge 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>
=A0
Cheers,
__
=A0/orben<= br clear=3D"all">

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