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: Tue, 14 Apr 2009 19:18:25 -0700 Message-ID: <1239761905.6516.20.camel@dell-desktop.example.com> References: <87ab6ngdjb.fsf@tunes.org> <873acclilz.fsf@ambire.localdomain> <87ws9odt9v.fsf@tunes.org> <87vdp8szuq.fsf@xemacs.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1239761926 11865 80.91.229.12 (15 Apr 2009 02:18:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Apr 2009 02:18:46 +0000 (UTC) Cc: "Stephen J. Turnbull" , bpt@tunes.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 15 04:20:04 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 1LtujM-0005rP-FR for ged-emacs-devel@m.gmane.org; Wed, 15 Apr 2009 04:20:04 +0200 Original-Received: from localhost ([127.0.0.1]:58883 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ltuhx-0005VY-O9 for ged-emacs-devel@m.gmane.org; Tue, 14 Apr 2009 22:18:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ltuht-0005VT-6V for emacs-devel@gnu.org; Tue, 14 Apr 2009 22:18:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ltuho-0005UZ-CV for emacs-devel@gnu.org; Tue, 14 Apr 2009 22:18:32 -0400 Original-Received: from [199.232.76.173] (port=59515 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ltuho-0005UU-8A for emacs-devel@gnu.org; Tue, 14 Apr 2009 22:18:28 -0400 Original-Received: from smtp161.iad.emailsrvr.com ([207.97.245.161]:52133) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ltuhn-0004mD-UZ for emacs-devel@gnu.org; Tue, 14 Apr 2009 22:18:28 -0400 Original-Received: from relay26.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay26.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 214A71B400A; Tue, 14 Apr 2009 22:18:27 -0400 (EDT) Original-Received: by relay26.relay.iad.mlsrvr.com (Authenticated sender: lord-AT-emf.net) with ESMTPSA id 57AA31B4009; Tue, 14 Apr 2009 22:18:26 -0400 (EDT) In-Reply-To: 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:110292 Archived-At: On Tue, 2009-04-14 at 17:14 -0400, Richard M Stallman wrote: > Basically what you're saying is "OK, let's impose an arbitrary total > ordering on the changes." Indeed that makes writing the collaborative > tool easier, but it also undermines collaboration by giving priority > to getting there *first* rather than doing it *better*. > > With all due respect, I think that is a misunderstanding of the issue. > We are talking about editing conflicts on timescales of a few seconds. > If two people are trying to edit the same part of the text at the same > time, they are stepping on each other's feet. Which one does the > stepping "better" is hardly an issue. You still need a way to keep remote buffers in sync and to re-sync them after temporary netsplits. The issue Stephen is worried about is that the proposal offered is to ignore that problem and assume a reliable network. FWIW I think Stephen's concerns are valid but that there is value in a short experimental project that ignores the problem to get something basic working - at least as long as there is some confidence that the solution to the simpler problem stands a good chance of growing into a solution for the more general problem. Stephen is right on strategy here but the offered tactic might have some value anyway. (Or it might not, I'm not evaluating.) -t