From: Thomas Lord <lord@emf.net>
To: Thien-Thi Nguyen <ttn@gnuvola.org>
Cc: Brian Templeton <bpt@tunes.org>, emacs-devel@gnu.org
Subject: Re: GSoC: collaborative editing
Date: Mon, 13 Apr 2009 09:11:12 -0700 [thread overview]
Message-ID: <1239639072.6492.16.camel@dell-desktop.example.com> (raw)
In-Reply-To: <873acclilz.fsf@ambire.localdomain>
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 <bpt@tunes.org>
> () 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
next prev parent reply other threads:[~2009-04-13 16:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-11 20:07 GSoC: collaborative editing Brian Templeton
2009-04-12 18:02 ` Michael Albinus
2009-04-13 1:22 ` Miles Bader
2009-04-13 9:08 ` Michael Albinus
2009-04-13 14:43 ` Thien-Thi Nguyen
2009-04-13 16:11 ` Thomas Lord [this message]
2009-04-13 22:04 ` Brian Templeton
2009-04-13 22:49 ` Thomas Lord
2009-04-14 3:41 ` Brian Templeton
2009-04-14 5:24 ` Thomas Lord
2009-04-13 22:52 ` Thomas Lord
2009-04-14 10:42 ` Thien-Thi Nguyen
2009-04-15 2:03 ` Thomas Lord
2009-04-13 17:44 ` Stefan Monnier
2009-04-13 23:10 ` Richard M Stallman
2009-04-13 23:32 ` Brian Templeton
2009-04-14 3:01 ` Stephen J. Turnbull
2009-04-14 4:02 ` Brian Templeton
2009-04-14 7:29 ` Stephen J. Turnbull
2009-04-14 9:09 ` Brian Templeton
2009-04-15 2:02 ` Thomas Lord
2009-04-14 21:14 ` Richard M Stallman
2009-04-15 2:18 ` Thomas Lord
2009-04-15 1:19 ` Brian Templeton
2009-04-15 1:27 ` Brian Templeton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1239639072.6492.16.camel@dell-desktop.example.com \
--to=lord@emf.net \
--cc=bpt@tunes.org \
--cc=emacs-devel@gnu.org \
--cc=ttn@gnuvola.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.