From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Brian Templeton Newsgroups: gmane.emacs.devel Subject: Re: GSoC: collaborative editing Date: Mon, 13 Apr 2009 19:32:28 -0400 Organization: TUNES Project Message-ID: <87ws9odt9v.fsf@tunes.org> References: <87ab6ngdjb.fsf@tunes.org> <873acclilz.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1239665628 8812 80.91.229.12 (13 Apr 2009 23:33:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Apr 2009 23:33:48 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 14 01:35:07 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LtVg9-0004Ut-Fl for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 01:35:05 +0200 Original-Received: from localhost ([127.0.0.1]:44566 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtVek-0001QH-OU for ged-emacs-devel@m.gmane.org; Mon, 13 Apr 2009 19:33:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtVef-0001Q2-J4 for emacs-devel@gnu.org; Mon, 13 Apr 2009 19:33:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtVdz-00019z-Ui for emacs-devel@gnu.org; Mon, 13 Apr 2009 19:33:32 -0400 Original-Received: from [199.232.76.173] (port=50457 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtVdz-00019w-OP for emacs-devel@gnu.org; Mon, 13 Apr 2009 19:32:51 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:48043 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LtVdz-0004G8-7E for emacs-devel@gnu.org; Mon, 13 Apr 2009 19:32:51 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LtVds-0007AQ-IM for emacs-devel@gnu.org; Mon, 13 Apr 2009 23:32:44 +0000 Original-Received: from cpe-071-070-209-067.nc.res.rr.com ([71.70.209.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Apr 2009 23:32:44 +0000 Original-Received: from bpt by cpe-071-070-209-067.nc.res.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Apr 2009 23:32:44 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 73 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpe-071-070-209-067.nc.res.rr.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux) Cancel-Lock: sha1:VdMHCr1CZdEVhK5dh/NEFq2F1vM= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:110251 Archived-At: Thien-Thi Nguyen writes: > () Brian Templeton > () 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.