From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Phil Hagelberg Newsgroups: gmane.emacs.devel Subject: Re: obby Date: Mon, 11 May 2009 09:25:38 -0700 Message-ID: <873abbr4hp.fsf@hagelb.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242059171 31517 80.91.229.12 (11 May 2009 16:26:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 May 2009 16:26:11 +0000 (UTC) Cc: Jeff Kowalczyk To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 11 18:25:55 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 1M3YK8-0004t5-1g for ged-emacs-devel@m.gmane.org; Mon, 11 May 2009 18:25:52 +0200 Original-Received: from localhost ([127.0.0.1]:60511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3YK7-0000Rm-Dw for ged-emacs-devel@m.gmane.org; Mon, 11 May 2009 12:25:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M3YK3-0000RF-28 for emacs-devel@gnu.org; Mon, 11 May 2009 12:25:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M3YJy-0000P9-6h for emacs-devel@gnu.org; Mon, 11 May 2009 12:25:46 -0400 Original-Received: from [199.232.76.173] (port=35651 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M3YJx-0000Oy-TH for emacs-devel@gnu.org; Mon, 11 May 2009 12:25:41 -0400 Original-Received: from caiajhbdcaib.dreamhost.com ([208.97.132.81]:34010 helo=spunkymail-a16.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M3YJx-0007Vt-Je for emacs-devel@gnu.org; Mon, 11 May 2009 12:25:41 -0400 Original-Received: from dynabook (c-24-19-45-181.hsd1.wa.comcast.net [24.19.45.181]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by spunkymail-a16.g.dreamhost.com (Postfix) with ESMTP id A19EC7B397; Mon, 11 May 2009 09:25:26 -0700 (PDT) In-Reply-To: (Jeff Kowalczyk's message of "Sun, 10 May 2009 17:29:45 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) 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:110825 Archived-At: Jeff Kowalczyk writes: > On Sun, 10 May 2009 15:53:21 -0400, Richard M Stallman wrote: >> Gobby is a collaborative editing system which >> uses a library called obby. (See gobby.0x539.de/ .) >> >> Is it feasible to make this work in Emacs? > > Phil Hagelberg previously released an Emacs implementation compatible with > obby-0.3: My implementation has since moved: http://github.com/technomancy/dotfiles/blob/63aac563d5f2417a7500942d2ac392c118d1d539/.emacs.old/ebby.el There are two major problems with my implementation. First, it's only compatible with a version of the obby protocol that is over three years out of date. Secondly, my knowledge of the protocol came from packet-sniffing since the protocol was undocumented at the time and I don't know C, so it doesn't do any inclusion transformation. This is necessary to support handling conflicts when two people edit the same portion of the document at the same time. This means that each client connected will eventually converge from having the same text for any given session unless they are on a near-zero-latency network. I had planned to revisit the problem once the new implementation of the obby protocol and client (now called Infinote) had been released. But implementing inclusion transformation is very difficult. By the way, this is a textbook case for why we would want to support dynamic linking. The reference implementation of the Infinote protocol, libinfinote, is released under the LGPL, so it would save a great deal of effort to be able to use that rather than creating a new, independent, under-manned implementation from scratch. It's especially hard to get motivated to sink that much effort into an alternate implementation when you know it would be much easier and more robust to link to an existing Free one. -Phil