From: Brian Templeton <bpt@tunes.org>
To: emacs-devel@gnu.org
Subject: Re: GSoC: collaborative editing
Date: Mon, 13 Apr 2009 18:04:38 -0400 [thread overview]
Message-ID: <878wm4fbwp.fsf@tunes.org> (raw)
In-Reply-To: 1239639072.6492.16.camel@dell-desktop.example.com
Thomas Lord <lord@emf.net> writes:
> On Mon, 2009-04-13 at 16:43 +0200, Thien-Thi Nguyen wrote:
>> () Brian Templeton <bpt@tunes.org>
>> 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?
next prev parent reply other threads:[~2009-04-13 22:04 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
2009-04-13 22:04 ` Brian Templeton [this message]
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=878wm4fbwp.fsf@tunes.org \
--to=bpt@tunes.org \
--cc=emacs-devel@gnu.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.