On Sat, 2009-10-31 at 14:05 -0400, Paul Davis wrote: > On Sat, Oct 31, 2009 at 1:40 PM, David Robillard <[email protected]> wrote: > > On Sat, 2009-10-31 at 17:35 +0100, [email protected] 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
