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, Samuel Loury <konubinix@gmail.com>
Subject: Re: colorg: Protocol [was: Re: Rudel - Real-Time collaborative editing of Org-Mode files]
Date: Mon, 1 Apr 2013 22:46:24 +0200	[thread overview]
Message-ID: <CABf3pC=d0fLJ0tJdtPevsfPEz-=meOmhENRu9Gg-mMWPphxXFg@mail.gmail.com> (raw)
In-Reply-To: <86bocrn81u.fsf@iro.umontreal.ca>

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

Hi François,

I recently read an interesting article on Convergent and Commutative
Replicated Data Types (
http://hal.inria.fr/docs/00/55/55/88/PDF/techreport.pdf) which happened to
have a section called "Co-operative text editing" that seems spot on for
the problem you are trying to solved. They mention two existing solutions -
Logoot and Treedoc - that might be worth investigating...

I'm not saying that any of these will solve the problem, but by nature (and
my heavy schooling in Math) I am too lazy not to consider stealing a
solution instead of inventing my own! ;-)


On Mon, Jan 14, 2013 at 3:38 PM, François Pinard <pinard@iro.umontreal.ca>wrote:

> Samuel Loury <konubinix@gmail.com> writes:
> > But instead of creating your own protocol, have you thought about
> > extending an already existing one?
> Yes, of course.  My goal is getting some solution, not creating my own
> thing.  I only tried to look at the internals of Rudel and
> Etherpad-lite, and also to read some literature on the topic, starting
> with Wikipedia.  In all cases, I felt stupid and overwhelmed. :-)  This
> is not simple, as far as I can see.
> > I see that you have read negative comments about tools using the obby
> > protocol, but have you read about the protocol itself?
> Besides Rudel, no.
> > By recreating a new protocol, you might be facing the same issues in
> > synchronization that gooby faced at some time and spending useless
> > effort trying to fix it.
> While not being fully sure, I think I have some understanding of the
> problem, and the solution I have in head might have no issue.  Its
> optimization is going to be a bit hairy however, and there lies the
> danger for introducing errors.  My fix would then be to not optimize, so
> with at least an inefficient solution, the effort is not useless. :-).
> > As far as I can see, the only thing that appears to be missing in the
> > obby protocol is the possibility to move entries without deleting and
> > reinserting.  This makes sense since it is specific to outlined
> > documents.  Why not adding this feature to the obby protocol?
> Because of the bad press, which gave me the unverified impression that
> by adopting Obby, I would have to spouse its problems, and get to solve
> them.  I guess people much more brilliant than me already tried, and
> failed or abandoned, so I just have no chance of succeeding :-).
> It sounds important to me, for Org mode, to support some "Move Block"
> operation, which combines delete and reinsert the same contents as a
> single operation instead of two, as I suspect this is frequent when
> someone is reorganize an Org outline, and I would ideally like that
> people editing within a block which is being moved by someone else does
> barely notice s/he is being shuffled elsewhere.  This is an Org
> specialty, that is unlikely part of other protocols, and this
> consideration pushed me into attempting something.  Not that I currently
> have a "Move Block" operation in the protocol, but it should be easier
> to add to something that I well understand.
> > By the way, I tried this week end gobby server 0.4 and rudel client
> > (last git version) and it did not manage to connect to the gobby server
> > while a gobby client 0.4 succeeded. So sad...
> I also got quick failures in my tries, of many kinds.
> > [1] http://gobby.0x539.de/trac/wiki/AnnotatedObbySession
> Thanks for this one, which I did not see.  I'll take a closer look!
> > If the obby protocol or any other RTCE protocol does not fit your needs
> > causing the creation of a new protocol, I think it would be a good idea
> > to write why on your wiki page.
> I'm saving these messages and recycling their content on the Wiki.  I
> should get more documentation on the Wiki, but did not have much time
> since I started, Friday evening, as I rather wanted to push on the code
> to have by Sunday at least some skeleton that moves a bit.  And even
> then, I took the time to move some previous comments to the Wiki, and
> explain at least the current state of protocol.  Documenting early helps
> at avoiding design errors.
> > I can't wait to see RTCE of org document!
> Ista Zahn published a working solution on the Wiki, that one could use
> if in a hurry.  It is said to work well, see:
>    https://github.com/pinard/ColOrg/wiki/emacsclient
> François


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

      reply	other threads:[~2013-04-01 20:46 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
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 [this message]

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='CABf3pC=d0fLJ0tJdtPevsfPEz-=meOmhENRu9Gg-mMWPphxXFg@mail.gmail.com' \
    --to=torben.lehoff@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=konubinix@gmail.com \
    --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).