From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Fran=C3=A7ois_Pinard?= Subject: Re: colorg: Protocol [was: Re: Rudel - Real-Time collaborative editing of Org-Mode files] Date: Mon, 14 Jan 2013 09:38:53 -0500 Message-ID: <86bocrn81u.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> <86r4mcz18p.fsf@iro.umontreal.ca> <86d2xasbjm.fsf@iro.umontreal.ca> <86obguou20.fsf_-_@iro.umontreal.ca> <87obgs12i3.fsf@konixwork.incubateur.ens-lyon.fr> 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]:51980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TulBg-00077F-TU for emacs-orgmode@gnu.org; Mon, 14 Jan 2013 09:39:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TulBe-0007QX-Uu for emacs-orgmode@gnu.org; Mon, 14 Jan 2013 09:38:56 -0500 Received: from 206-248-137-202.dsl.teksavvy.com ([206.248.137.202]:64186 helo=mercure.bureau.ubity.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TulBe-0007QQ-Mx for emacs-orgmode@gnu.org; Mon, 14 Jan 2013 09:38:54 -0500 In-Reply-To: <87obgs12i3.fsf@konixwork.incubateur.ens-lyon.fr> (Samuel Loury's message of "Mon, 14 Jan 2013 11:29:40 +0100") 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: Samuel Loury Cc: emacs-orgmode@gnu.org, Torben Hoffmann 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=C3=A7ois