On Thu, Dec 27, 2012 at 3:18 AM, François Pinard <pin...@iro.umontreal.ca>wrote:
> Eric Schulte <schulte.e...@gmail.com> writes: > > > Unfortunately Rudel doesn't appear to be maintained [...] > > Moreover, looking around, I saw a few comparisons and comments in which > other tools using the Obby protocol, which Rudel primarily supports, had > negative light. I also found out that the synchronization problem and > issues are far, far more complex than I initially thought. There are > really many avenues, while none seem perfect so far. > > > Rather than an Org-mode specific solution, I think adopting Rudel or > > developing something similar which provides emacs-wide support for > > standard collaborative editing protocols (assuming any currently exist) > > would be the best way forward. > > Agreed that any nice and general solution which overwhelms [not sure of > that word in English] Org, and even Emacs, should be considered more > tempting. An full Emacs Lisp solution would be a wrong solution, as the > protocol itself should be implemented without the need of Emacs. On the > other hand, any solution encumbered with explicit editing minutiae (make > this bold, change font, etc.) is less attractive, because it would mean > spurious and unwanted burden for Org files. > > In my wildest dreams :-), I would see real-time collaboration between > people with most participant working on the text of a document, I mean > what follow headers or the header text itself, while a few others > reorganize the structure by moving headers around. Moving headers > should be nothing more than moving headers, it should not imply deletion > followed by transmission of re-inserted text, as this would seriously > disrupt those altering the text: the re-organization should happen > magically under participant's feet while they are editing, nice and > easy. > > Now, the notion of structure may be rendered by a synchronization > mechanism in a way which overwhelms Org by the concept of efficiently > handled nested documents, an single Org file would itself be a > collection of such nested documents. Just an idea of course, there > might be other avenues as well which are acceptable as long as they > allow structure reorganization without text being transmitted again. > > I have the vague, and admittedly strange intuition that Git internals > have the potential for representing nested documents through the > repository structure, for discovering both structural and textual > overhaul, and even for transmitting differences over the wires. But I > doubt, all efficient that Git may already be, that it would be speedy > enough to be part of a solution. That might even be elegant, so I hope > I'm wrong on the speed issue :-). > Not sure if it would be speedy enough, but gitit is based on git and since it is a wiki running on top of git with the ability to edit the documents either through a traditional wiki frontend in a browser or as a raw file in an editor of your choice on your own machine. Inventing a protocol to deal with synchronisation is not trivial, so a good starting point might be gitit or raw git with the intention of learning about what the real issues are before creating a system from scratch to solve what might not be the right problem to solve. I have not used org enough to be able to judge these issues, but I would like to have a good multi-user solution since org seems to be one of the better ways to collaborate. <snip> Cheers, __ /orben -- http://www.linkedin.com/in/torbenhoffmann
