Re: GSoC: collaborative editing

[Brian Templeton <bpt@tunes.org>]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Brian Templeton <bpt@tunes.org>
> () Sat, 11 Apr 2009 16:07:20 -0400
>
>    [introduction]
>
> Sounds interesting.  Have you thought about a peer-to-peer architecture?
> I don't know if i'm qualified to be a sponsor, but i wouldn't mind
> helping, w/ the caveat that the design move away from requiring a
> separate server and towards peer-to-peer.

I have considered a P2P architecture, but as Stefan mentions, that makes
it much harder to ensure consistency, and P2P algorithms are
considerably more complicated than algorithms that rely on a central
server.

>    1. A precise change reporting mechanism, replacing
>       {before,after}-change-functions.  This will require cooperation
>       with other Emacs developers and must not reduce performance for
>       applications not requiring precise change reporting.
>
> Why must these be replaced?

Emacs does not report changes precisely enough to allow one to infer the
sequence of basic editing operations performed from a sequence of calls
to a *-change-functions hook. For example, substituting a character in a
region results in a single large change being reported. Currently it's
possible to write a client that would work correctly as long as the user
limits themselves to simple editing operations, but naïve change hook
functions will detect operations incorrectly in many situations (e.g.,
when filling paragraphs).

>    2. A transclusion system, which will be used as a test of the new change
>       reporting mechanism.
>
>    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.
>
>    4. End-user documentation, including a user guide published either as
>       Texinfo or on the EmacsWiki.
>
>    5. An updated version of the Emacs Lisp manual describing the new change
>       reporting mechanism.
>
>    [Plan: discuss change functions and then] debitrot the Erlang server
>    and add support for a simple binary protocol in addition to the HTTP
>    interface used by the old JS and Flash clients.
>
> Probably you want to avoid binary protocol unless absolutely necessary.
> Why not translate the existing protocol to use Emacs-`read'able sexps?

My wording was misleading; I only meant a protocol more compact than
HTTP, which is very verbose for applications like this.

>    During the last half of the program I will work on the client itself
>    -- implementing the revised Jupiter algorithm, support for the binary
>    protocol, a simple interactive client, lists of remote users,
>    visualization of the activity of other users (e.g. coloring spans of
>    text according to who last edited it, indicating others' point
>    positions, etc.), and so on.
>
> Many of these features are supplied by Emacs itself.  Indeed, Emacs is
> already a "simple interactive client" of its change-recording internals.

But not a simple interactive client for displaying changes made in
_other_ editors. Some of them are easy to implement, but none of these
features are supplied by Emacs itself.