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 <pin...@iro.umontreal.ca>wrote: > Samuel Loury <konubi...@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
