[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release plans

From: Thien-Thi Nguyen
Subject: Re: Release plans
Date: Sun, 31 Aug 2008 11:27:08 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

() Thomas Lord <address@hidden>
() 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

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]


   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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]