Re: GSoC: collaborative editing

[Thomas Lord]

I have been organizing some materials about
a "Collaboration WebOS" project: a project to
help many free software projects - like Emacs - 
build in collaboration features in coordinated
ways.   See http://basiscraft.com


On Mon, 2009-04-13 at 16:43 +0200, Thien-Thi Nguyen wrote:
> () Brian Templeton <address@hidden>
> () Sat, 11 Apr 2009 16:07:20 -0400
> 
>    [introduction]
> 
> Sounds interesting. 
[...]
>    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

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/
   )

Reasons and Cautions:

a. Caution: "mobwrite" currently makes the same 
   mistake of using a custom server.  To make
   it acceptable for this project, ideally
   it would be modified to use XMPP.

b. Caution: "mobwrite" is new and experimental.
   The design needs to be scrutinized with care.

c. Caution: "mobwrite" is a project of Google
   Inc.   Past experience with free software 
   development projects that become intertwined
   with development corporations of for-profit 
   firms is that the for-profit firm's motives
   to cooperate may prove fickle.   It is easy 
   to wind up with a situation where the for-profit
   firm benefits for its own purposes, but the
   cause of software freedom gains little or even
   loses ground.

d. Reason: Perhaps using "mobwrite" can save work.

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.




-t