Plugin project proposal

[Nicolas Williams]

On Thu, Jul 15, 2010 at 06:36:57PM -0400, Greg Hudson wrote:
> > This is where the proposal to just use straight exported functions is
> > a lot simpler.  If the common operation is to add new functions,
> > that's the better design.
> 
> As a dev community, we still seem to have some reservations about
> one-symbol-per-method.  Stated reservations include:
> 
>   * The provider code has to change depending on whether it's being used
> as a built-in implementation or a dynamic object.  These changes can be
> automated, but automatically generated code is more difficult to debug
> through.

Automatically generated code isn't like to change, so once debugged it
stays debugged.  That code will also be small, comparable to the v-table
provider code in the v-table case.  In fact, one could just auto-
generate that code in the v-table scheme too; if a plugin interface has
enough function calls that begins to be desirable.  Again, the two
approaches are equivalent.  One requires writing more provider code.

>   * If the pluggable interface is completely revised, a vtable clearly
> identifies to the provider which set of functions is going to be used;
> the provider doesn't have to worry about being used in a "v1.5" mode
> where some functions are used from each interface revision.

I find the above argument specious as it ignores the fact that you could
always do version negotiation in an init function.  (You're likely going
to need an init function anyways.)

Repeating any of these arguments, if I disagree that they make a
difference, isn't going to change my views.  New arguments might at
least be more fun, even if they were no better :)

So far the only technical argument one way or the other than I think is
remotely likely to be dispositive is the dlsym() performance argument.
Numbers?

Of course, you don't actually have to measure dlsym() performance.  You
can just tell me I'm on the rough side of consensus and be done -- it
does appear that I am on the rough side of consensus.

Nico
--