[Top][All Lists]
[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?
>
>
>
Re: GSoC: collaborative editing, Stefan Monnier, 2009/04/13
Re: GSoC: collaborative editing, Brian Templeton, 2009/04/13
- Re: GSoC: collaborative editing, Stephen J. Turnbull, 2009/04/13
- Re: GSoC: collaborative editing, Brian Templeton, 2009/04/14
- Re: GSoC: collaborative editing, Stephen J. Turnbull, 2009/04/14
- Re: GSoC: collaborative editing, Brian Templeton, 2009/04/14
- Re: GSoC: collaborative editing, Thomas Lord, 2009/04/14