[LAD] State of Plugin API's

[David Robillard]

On Sat, 2009-10-31 at 14:05 -0400, Paul Davis wrote:
> On Sat, Oct 31, 2009 at 1:40 PM, David Robillard <dave at drobilla.net> wrote:
> > On Sat, 2009-10-31 at 17:35 +0100, fons at kokkinizita.net wrote:
> >> On Sat, Oct 31, 2009 at 12:08:54PM -0400, David Robillard wrote:
> >>
> >> > ...  This is exactly
> >> > like blaming the shared library mechanism for the fact that there's no
> >> > open source shared library to do realtime granular resynthesis, or
> >> > whatever.
> >>
> >> It's very different. If I want to write a library to do
> >> realtime granular synthesis I don't have to extend the
> >> shared library mechanism first, or write a new dynamic
> >> linker.
> >
> > You don't need to extend the extension mechanism first (I don't even
> > know what this means...) or write a new host either.
> >
> > Shared library, you get a thing by filename, it has code in it.
> > Extension, you get a thing by URI, it has code in it.
> >
> > It is not "very different" at all.
> 
> that's just one side of the equation.
> 
> having found the thing, what gets done with it? there are two things
> with a shared library:

There is a pervasive theme of people criticizing what they do not
understand here.  It is generally not wise to do that ;)

>   * run time linker gets it all nicely set up in the address space of
> the process

Free, since this is all (likely) taking place in memory anyway.

>   * parts of the app call functions in the library API to get things done

Identical.

There is no other side of the equation because the whole thing is so
painfully simply.  You get your pointer.  Done.

They are both literally just mechanisms to get a pointer to some
code/data by name.  It's really quite simple...  I'm not sure where this
conception that there's some kind of hard to understand complex
mechanism involved here comes from, but there really isn't at all.
"Mechanism" isn't even an appropriate word, really, it's just a
function.  It's as straightforward as straightforward can be.  Look at
the header:

const void* (*extension_data)(const char * uri);

This is the "extension mechanism" for plugins.  You give it a URI, it
gives you something back.  That's it.  Implementing, and calling, such a
thing is obviously trivial.  The opposite case for adding stuff for the
host to provide for the plugin is similar.

Best practice is to return a struct filled with function pointers (so
things can be added to it without breakage).

In slightly higher level terms, what this allows you to do is add
whatever functions you want to any plugin, in a very easy and
straightforward manner with no bureaucratic overhead or anything else
getting in your way.  Not actually documenting things is obviously
foolish, but feel free, just like shared libraries.  How can this
mechanism possibly be to blame for things not being implemented?
There's virtually no overhead whatsoever to getting the job done, that's
the entire point!

Again, this lets you very easily add whatever functions to a plugin you
want.  There is no voodoo here.  I am not obscuring any details, or
anything like that.  That's really it.  You can add whatever you want,
extremely easily.

Blaming the extension mechanism for such and such not being implemented
is every bit as nonsensical as blaming the shared library mechanism for
the same.  You can easily write whatever functions you want, in either
case.

-dr