emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Torben Hoffmann <torben.lehoff@gmail.com>
To: "François Pinard" <pinard@iro.umontreal.ca>
Cc: emacs-orgmode@gnu.org
Subject: Re: Rudel - Real-Time collaborative editing of Org-Mode files
Date: Tue, 1 Jan 2013 23:04:31 +0100	[thread overview]
Message-ID: <CABf3pCm7JAUxqJsQK-ytkVza_JDZMk4qTA0iTZK2+zs7GUPgPA@mail.gmail.com> (raw)
In-Reply-To: <86r4mcz18p.fsf@iro.umontreal.ca>

[-- Attachment #1: Type: text/plain, Size: 3624 bytes --]

On Thu, Dec 27, 2012 at 3:18 AM, François Pinard <pinard@iro.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.  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.




[-- Attachment #2: Type: text/html, Size: 4417 bytes --]

  reply	other threads:[~2013-01-01 22:04 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
2013-01-01 22:04           ` Torben Hoffmann [this message]
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:

  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=CABf3pCm7JAUxqJsQK-ytkVza_JDZMk4qTA0iTZK2+zs7GUPgPA@mail.gmail.com \
    --to=torben.lehoff@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=pinard@iro.umontreal.ca \


* 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


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).