Re: GSoC: collaborative editing

[Brian Templeton]

Thomas Lord <address@hidden> writes:

> On Mon, 2009-04-13 at 16:43 +0200, Thien-Thi Nguyen wrote:
>> () Brian Templeton <address@hidden>
>>    3. A collaborative editing system using a modified version of the
>>       Jupiter algorithm, comprising:
>> 
>>       - A client written in Emacs Lisp.
>>       - A modified version of an existing server written in Erlang.
>> 
>> I think a server written in Emacs Lisp would gain more traction.
>
> Please consider this third alternative which I 
> think has advantages to both:
>
> 1. Do not write a custom server.
> 2. Use a chat server (such as a Jabber implementation).
> 3. If some server-side computation is needed other
>    than just forwarding messages in the manner of a chat
>    session, write that new server-side code as a 
>    chat client.
>
> Reasons:
>
> a. "no new server" means less work
> b. "no new server" means less work for server
>    administrators if they are already running
>    a chat server
> c. "use Jabber (XMPP)" means that the same
>    message bus can be shared with other programs
>    such as the "collaborative whiteboard" feature
>    of Inkscape
> d. XMPP implementations are actively maintained
>    and aggressively improved.  It is hard to image
>    a new, less general-purpose server "catching up"
>    and to catch up suggests doing a lot of redundent
>    work

I have already written a server, so using XMPP wouldn't save any work in
the short run. I evaluated XMPP when I wrote the server and wasn't able
to determine whether using Jabber as a message bus for a Jupiter-based
protocol would require misusing XMPP, since some server-side computation
and modification of client messages is required. But I'm not averse to
using Jabber as a message bus if it wouldn't be considered a misuse of
the protocol, and it would certainly be a good fit if I implemented an
algorithm for P2P editing, which wouldn't require server-side
computation/message modification at all.

The current server is written in Erlang; it would be only moderately
difficult to adapt it to work with ejabberd's mod_muc.

> There is a second question.  What payload goes
> in chat messages?   How are mutually remote buffers
> synchronized.   In that area I suggest:
>
> 1. Carefully evaluating and considering adopting
>    (and helping to adapt) the "mobwrite" 
>    system of "diff sync" (see
>    http://code.google.com/p/google-mobwrite/
>    )
>
I am planning to use operation transformation, which is also used by
most existing collaborative editors (Gobby, SubEthaEdit, etc.).
Operation transformation is easier to implement and more elegant than
differential synchronization, IMO. In the context of real-time
collaborative editing of text documents, DS does not seem to solve any
actual problems that aren't already solved by OT.

> b. Caution: "mobwrite" is new and experimental.
>    The design needs to be scrutinized with care.
>
Yes, and I don't want to have to be the one to scrutinize it. There is a
great deal of theoretical work available on OT approaches, and several
algorithms have been proven correct; I'd rather rely on a functioning
network (i.e., one that doesn't drop messages constantly) than attempt
to prove the correctness of 'fuzzy' matching algorithms and
'best-effort' patching algorithms.

> e. Reason: Since other editors are considering 
>    or being modified to use "mobwrite", perhaps this
>    approach can ultimately allow collaborative sessions
>    in which some users are using "emacs" while others
>    use "bespin" or "vim" or what have you.
>
Which editors? Are any editors currently using mobwrite, besides editors
specifically written to use mobwrite?