From: "François Pinard" <pinard@iro.umontreal.ca>
To: Samuel Loury <konubinix@gmail.com>
Cc: emacs-orgmode@gnu.org, Torben Hoffmann <torben.lehoff@gmail.com>
Subject: Re: colorg: Protocol [was: Re: Rudel - Real-Time collaborative editing of Org-Mode files]
Date: Mon, 14 Jan 2013 09:38:53 -0500 [thread overview]
Message-ID: <86bocrn81u.fsf@iro.umontreal.ca> (raw)
In-Reply-To: <87obgs12i3.fsf@konixwork.incubateur.ens-lyon.fr> (Samuel Loury's message of "Mon, 14 Jan 2013 11:29:40 +0100")
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
next prev parent reply other threads:[~2013-01-14 14:39 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 [this message]
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=86bocrn81u.fsf@iro.umontreal.ca \
--to=pinard@iro.umontreal.ca \
--cc=emacs-orgmode@gnu.org \
--cc=konubinix@gmail.com \
--cc=torben.lehoff@gmail.com \
/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).