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.
<snip>
Cheers,
__
/orben
--
http://www.linkedin.com/in/torbenhoffmann
[-- Attachment #2: Type: text/html, Size: 4417 bytes --]
next prev parent 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:
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=CABf3pCm7JAUxqJsQK-ytkVza_JDZMk4qTA0iTZK2+zs7GUPgPA@mail.gmail.com \
--to=torben.lehoff@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=pinard@iro.umontreal.ca \
/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).