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 22:24:30 -0700 Message-ID: <1239686670.6492.240.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> <1239662980.6492.207.camel@dell-desktop.example.com> <87zlejdhqn.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 1239686701 15472 80.91.229.12 (14 Apr 2009 05:25:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Apr 2009 05:25:01 +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 07:26:19 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 1LtbA1-0001vd-3V for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 07:26:18 +0200 Original-Received: from localhost ([127.0.0.1]:45061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ltb8c-0002pO-4M for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 01:24:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ltb8U-0002pJ-Et for emacs-devel@gnu.org; Tue, 14 Apr 2009 01:24:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ltb8O-0002lp-Lm for emacs-devel@gnu.org; Tue, 14 Apr 2009 01:24:40 -0400 Original-Received: from [199.232.76.173] (port=37467 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ltb8O-0002le-CU for emacs-devel@gnu.org; Tue, 14 Apr 2009 01:24:36 -0400 Original-Received: from smtp181.iad.emailsrvr.com ([207.97.245.181]:49914) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ltb8O-0002ep-1T for emacs-devel@gnu.org; Tue, 14 Apr 2009 01:24:36 -0400 Original-Received: from relay28.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay28.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id CA34C1B4011; Tue, 14 Apr 2009 01:24:29 -0400 (EDT) Original-Received: by relay28.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 097981B4009; Tue, 14 Apr 2009 01:24:28 -0400 (EDT) In-Reply-To: <87zlejdhqn.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:110262 Archived-At: On Mon, 2009-04-13 at 23:41 -0400, Brian Templeton wrote: > 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. Oh, well. It will eventually do both. > 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.) Sure. I think OT and diff sync mostly turn out the same except that diff sync synthesizes a fake edit stream from the buffer rather than capturing the actual edit stream. > [...] > > 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: > > > > Thanks. -t