From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torben Hoffmann Subject: Re: colorg: Protocol [was: Re: Rudel - Real-Time collaborative editing of Org-Mode files] Date: Mon, 1 Apr 2013 22:46:24 +0200 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> <86d2xasbjm.fsf@iro.umontreal.ca> <86obguou20.fsf_-_@iro.umontreal.ca> <87obgs12i3.fsf@konixwork.incubateur.ens-lyon.fr> <86bocrn81u.fsf@iro.umontreal.ca> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdca464d7c78904d952b61f Return-path: Received: from eggs.gnu.org ([208.118.235.92]:47715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMlcd-0008Qz-K1 for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 16:46:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMlcY-0001fv-3o for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 16:46:31 -0400 Received: from mail-qe0-f42.google.com ([209.85.128.42]:48943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMlcX-0001fl-VG for emacs-orgmode@gnu.org; Mon, 01 Apr 2013 16:46:26 -0400 Received: by mail-qe0-f42.google.com with SMTP id da11so1480203qeb.29 for ; Mon, 01 Apr 2013 13:46:25 -0700 (PDT) In-Reply-To: <86bocrn81u.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, Samuel Loury --047d7bdca464d7c78904d952b61f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Fran=E7ois, 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! ;-) Cheers, __ /orben On Mon, Jan 14, 2013 at 3:38 PM, Fran=E7ois Pinard wrote: > Samuel Loury 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=E7ois > --=20 http://www.linkedin.com/in/torbenhoffmann --047d7bdca464d7c78904d952b61f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Fran=E7ois,

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 st= ealing a solution instead of inventing my own! ;-)

Cheers, __
=A0/orben


On Mon, Jan 14, 2013 at 3:38 PM, Fran=E7ois 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. =A0My goal is getting some solution, not creating my = own
thing. =A0I only tried to look at the internals of Rudel and
Etherpad-lite, and also to read some literature on the topic, starting
with Wikipedia. =A0In all cases, I felt stupid and overwhelmed. :-) =A0This=
is not simple, as far as I can see.

> I see that you have read negative comments about tools using the obby<= br> > 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<= br> problem, and the solution I have in head might have no issue. =A0Its
optimization is going to be a bit hairy however, and there lies the
danger for introducing errors. =A0My fix would then be to not optimize, so<= br> 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<= br> > obby protocol is the possibility to move entries without deleting and<= br> > reinserting. =A0This makes sense since it is specific to outlined
> documents. =A0Why not adding this feature to the obby protocol?

Because of the bad press, which gave me the unverified impression tha= t
by adopting Obby, I would have to spouse its problems, and get to solve
them. =A0I 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&q= uot;
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. =A0This is an Org
specialty, that is unlikely part of other protocols, and this
consideration pushed me into attempting something. =A0Not that I currently<= br> have a "Move Block" operation in the protocol, but it should be e= asier
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 serve= r
> 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. =A0I'll take a closer look!

> If the obby protocol or any other RTCE protocol does not fit your need= s
> causing the creation of a new protocol, I think it would be a good ide= a
> to write why on your wiki page.

I'm saving these messages and recycling their content on the Wiki= . =A0I
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. =A0And even
then, I took the time to move some previous comments to the Wiki, and
explain at least the current state of protocol. =A0Documenting early helps<= br> 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 us= e
if in a hurry. =A0It is said to work well, see:

=A0 =A0https://github.com/pinard/ColOrg/wiki/emacsclient

Fran=E7ois



--
http://www.linkedin.com/in/t= orbenhoffmann
--047d7bdca464d7c78904d952b61f--