From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Fran=C3=A7ois_Pinard?= Subject: Re: Rudel - Real-Time collaborative editing of Org-Mode files Date: Wed, 26 Dec 2012 21:18:30 -0500 Message-ID: <86r4mcz18p.fsf@iro.umontreal.ca> References: <50D4AF62.2020401@gmail.com> <87txrcxq14.fsf@bzg.ath.cx> <86licmclle.fsf@iro.umontreal.ca> <86han9dho5.fsf@iro.umontreal.ca> <87k3s4ij3m.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:54118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1To33K-00061p-E2 for emacs-orgmode@gnu.org; Wed, 26 Dec 2012 21:18:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1To33J-0000yv-FI for emacs-orgmode@gnu.org; Wed, 26 Dec 2012 21:18:34 -0500 Received: from 206-248-137-202.dsl.teksavvy.com ([206.248.137.202]:60777 helo=mercure.bureau.ubity.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1To33J-0000yp-7l for emacs-orgmode@gnu.org; Wed, 26 Dec 2012 21:18:33 -0500 In-Reply-To: <87k3s4ij3m.fsf@gmail.com> (Eric Schulte's message of "Wed, 26 Dec 2012 14:44:45 -0700") 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: emacs-orgmode@gnu.org 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 :-). 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=C3=A7ois