From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: GSoC: collaborative editing Date: Mon, 13 Apr 2009 15:52:36 -0700 Message-ID: <1239663156.6492.209.camel@dell-desktop.example.com> References: <87ab6ngdjb.fsf@tunes.org> <873acclilz.fsf@ambire.localdomain> <1239639072.6492.16.camel@dell-desktop.example.com> <878wm4fbwp.fsf@tunes.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1239663175 3416 80.91.229.12 (13 Apr 2009 22:52:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Apr 2009 22:52:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Brian Templeton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 14 00:54:14 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 1LtV2Z-00044g-WC for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 00:54:12 +0200 Original-Received: from localhost ([127.0.0.1]:59943 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtV1B-0003I4-9Y for ged-emacs-devel@m.gmane.org; Mon, 13 Apr 2009 18:52:45 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtV17-0003Hq-CY for emacs-devel@gnu.org; Mon, 13 Apr 2009 18:52:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtV13-0003He-TS for emacs-devel@gnu.org; Mon, 13 Apr 2009 18:52:41 -0400 Original-Received: from [199.232.76.173] (port=60640 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtV13-0003Hb-QX for emacs-devel@gnu.org; Mon, 13 Apr 2009 18:52:37 -0400 Original-Received: from smtp181.iad.emailsrvr.com ([207.97.245.181]:47257) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LtV13-00013H-DL for emacs-devel@gnu.org; Mon, 13 Apr 2009 18:52:37 -0400 Original-Received: from relay8.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id D9F6220239F; Mon, 13 Apr 2009 18:52:36 -0400 (EDT) Original-Received: by relay8.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 348512022D1; Mon, 13 Apr 2009 18:52:36 -0400 (EDT) In-Reply-To: <878wm4fbwp.fsf@tunes.org> X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 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:110249 Archived-At: I should add that a previous GSoC project added a collaborative edit session feature to the Inkscape SVG editor: a "shared whiteboard" mode. I have not extensively tested it and I understand that the feature has some problems and was not realized as fully as the student aimed for at the start of the summer - but it is there, and at least somewhat works, and ... uses XMPP :-) -t On Mon, 2009-04-13 at 18:04 -0400, Brian Templeton wrote: > Thomas Lord writes: > > > On Mon, 2009-04-13 at 16:43 +0200, Thien-Thi Nguyen wrote: > >> () Brian Templeton > >> 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? > > >