emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC: collaborative editing


From: Thomas Lord
Subject: Re: GSoC: collaborative editing
Date: Mon, 13 Apr 2009 15:52:36 -0700

I should add that a previous GSoC
project added a collaborative edit session
feature to the Inkscape SVG editor: a 
"shared whiteboard" mode.

I have not extensively tested it and I understand
that the feature has some problems and was not realized
as fully as the student aimed for at the start of
the summer - but it is there, and at least somewhat
works, and ... uses XMPP :-)

-t



On Mon, 2009-04-13 at 18:04 -0400, Brian Templeton wrote:
> 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?
> 
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]