From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Sun, 31 Aug 2008 11:27:08 +0200 Message-ID: <873aklpmab.fsf@ambire.localdomain> References: <20080818210927.GD2615@muc.de> <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp> <87ljytkwpk.fsf@rattlesnake.com> <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp> <87vdxp27z6.fsf@uwakimon.sk.tsukuba.ac.jp> <87prnxe5hc.fsf@rattlesnake.com> <873aktck5d.fsf@uwakimon.sk.tsukuba.ac.jp> <87k5e5dsvq.fsf@rattlesnake.com> <48B44802.1080302@emf.net> <87ej4atczj.fsf@gmail.com> <48B78A75.8080103@emf.net> <803akoyrqy.fsf@tiny.isode.net> <48B7F59B.5060705@gmail.com> <48B84CA8.7080908@emf.net> <87zlmvd1xl.fsf@ambire.localdomain> <48B87DFE.80806@emf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1220175088 4368 80.91.229.12 (31 Aug 2008 09:31:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Aug 2008 09:31:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Thomas Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 31 11:32:23 2008 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 1KZjIC-0004SK-FQ for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 11:32:20 +0200 Original-Received: from localhost ([127.0.0.1]:49732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZjHD-00089h-Rn for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 05:31:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZjGK-0007dG-Ai for emacs-devel@gnu.org; Sun, 31 Aug 2008 05:30:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZjGI-0007ci-NN for emacs-devel@gnu.org; Sun, 31 Aug 2008 05:30:23 -0400 Original-Received: from [199.232.76.173] (port=56260 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZjGI-0007cc-AC for emacs-devel@gnu.org; Sun, 31 Aug 2008 05:30:22 -0400 Original-Received: from [151.61.142.27] (port=44561 helo=ambire.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KZjGH-0008PS-GZ for emacs-devel@gnu.org; Sun, 31 Aug 2008 05:30:22 -0400 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1KZjDB-0001yI-3J; Sun, 31 Aug 2008 11:27:09 +0200 In-Reply-To: <48B87DFE.80806@emf.net> (Thomas Lord's message of "Fri, 29 Aug 2008 15:53:50 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:103304 Archived-At: () Thomas Lord () Fri, 29 Aug 2008 15:53:50 -0700 You contrast [...] If you are going to have (2c) then you also implicitly have: (2c') emacs -- [shared buffer] -- any[*] [*] any program that knows the buffer data structure and sharing protocol In other words, (2c) is one possible API for a dynamic loader in Emacs. Instead of "contrast", you can look at shared buffers as the strength- (and thus complexity- and maintenance-burden-)reduced well-behaved little brother to the dynamic loader. This is because the focus is on sharing data, not the program counter. A shared buffer API is just as much an invitation to non-free add-ons as a dlopen API, but the shared buffer API is probably (I'd agree with you, if we're just kibbitzing) better for free software developers, better for Emacs maintainers, etc. If you keep the protocol focused on data, then you stay out of the scope of free software (modulo what GPLv3 brings to bear wrt patents). This is the primary {at,de}traction of this (and any network-protocol-based) approach. I think that there are leaks in that abstraction -- it's not quite as minimal and contained as I think you suggest. [design issues] OK. By what metric should we be invited to measure the compromise? and then how is the compromise implemented? and how does it perform? and what is it good for? These are good questions. I don't know their answers. thi