[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 09:11:12 -0700 |
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
Re: GSoC: collaborative editing, Stefan Monnier, 2009/04/13
Re: GSoC: collaborative editing, Brian Templeton, 2009/04/13