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! ;-)

Cheers,
__
 /orben


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
>



-- 
http://www.linkedin.com/in/torbenhoffmann