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 23:41:36 -0400 Organization: TUNES Project Message-ID: <87zlejdhqn.fsf@tunes.org> References: <87ab6ngdjb.fsf@tunes.org> <873acclilz.fsf@ambire.localdomain> <1239639072.6492.16.camel@dell-desktop.example.com> <878wm4fbwp.fsf@tunes.org> <1239662980.6492.207.camel@dell-desktop.example.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1239680570 4814 80.91.229.12 (14 Apr 2009 03:42:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Apr 2009 03:42:50 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 14 05:44:09 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 1LtZZA-0001oM-3Z for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 05:44:08 +0200 Original-Received: from localhost ([127.0.0.1]:34523 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtZXl-0001Ip-H9 for ged-emacs-devel@m.gmane.org; Mon, 13 Apr 2009 23:42:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtZXf-0001IB-PA for emacs-devel@gnu.org; Mon, 13 Apr 2009 23:42:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtZX1-0000jA-0j for emacs-devel@gnu.org; Mon, 13 Apr 2009 23:42:35 -0400 Original-Received: from [199.232.76.173] (port=40177 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtZX0-0000j0-PW for emacs-devel@gnu.org; Mon, 13 Apr 2009 23:41:54 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:43369 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 1LtZX0-0003LJ-9t for emacs-devel@gnu.org; Mon, 13 Apr 2009 23:41:54 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LtZWv-0007ID-Hh for emacs-devel@gnu.org; Tue, 14 Apr 2009 03:41:49 +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 ; Tue, 14 Apr 2009 03:41:49 +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 ; Tue, 14 Apr 2009 03:41:49 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 64 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:WTWMrSFgZPJ7IFl55ifmjMx+UBw= 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:110257 Archived-At: Thomas Lord writes: > On Mon, 2009-04-13 at 18:04 -0400, Brian Templeton wrote: >> Thomas Lord writes: [...] >> > 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. > > Does "operation transformation" mean taking a > log of edit commands and applying outcome-preserving > transformations upon it to compress it to a shorter > log of edit commands? > > If so, fwiw, from my background -- that *does* sound like > a much better approach. I could boor you for hours as to > why but ... well, why? No need. :-) Operation transformation does use outcome-preserving transformations, not for compressing the log of edit commands but to reconcile the effects of concurrently generated commands. My implementation will only require an inclusion transformation, which transforms an operation to "include" the effect of another operation, which allows one to avoid divergence of document state when edits are being applied concurrently. (For example, if Bob inserts a character at position 12 at the same time that Alice inserts five characters at position 0, Alice needs to shift the position of the insertion operation she recieves from Bob forward by five characters to take into account her own operation that Bob didn't know about.) [...] > It's a big topic, though, so it would help if I > were more certain you meant by "OT" what I take > you to mean. Can you point to some docs I can > read to make sure we're talking about the same thing? You can get a decent overview from the ACE project's evaluation of various algorithms: The Jupiter algorithm is described in this paper, also linked to in my initial post: An inclusion transformation function for operations on text documents is defined in this paper: