Re: Release plans

[Thien-Thi Nguyen <ttn@gnuvola.org>]

() Thomas Lord <lord@emf.net>
() 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