[LV2] lv2_descriptor() considered harmful

[David Robillard]

On Thu, 2012-03-15 at 19:43 +0100, Stefan Kersten wrote:
> On 3/15/12 7:12 PM, David Robillard wrote:
> > In related news, I have discovered a different quasi-problem with this
> > API.  I was hoping having a LV2_Lib_Descriptor would remove the need for
> > all static data in the lib.  However, the library descriptor is not
> > available to LV2_Descriptor::instantiate, so if you load a list of
> > plugins at discovery time, you can't get at it in instantiate, unless:
> >
> >   * You have static data in the library, shared between all instances of
> > that library
> >
> >   * You calculate all that stuff again, for every plugin instantiation
> >
> > This kinda sucks, but I see no solution.  It makes me wonder if a
> > library descriptor is even worth it.
> 
> i thought the problem was not so much static data per se, but getting 
> control over initialization and destruction? if you want to avoid static 
> data you'll need to call lv2_lib_descriptor once and pass the 
> LV2_Lib_Descriptor to LV2_Descriptor::instantiate, i don't see any other 
> way. i personally consider it important to be able to obtain the host's 
> feature set when the library is loaded.

Yes, that is how it should work.  Unfortunately we can't really change
LV2_Descriptor::instantiate.

The thing is, is making static data rely on the host's feature set a
good idea?  This is a /shared/ library, after all.

Since you unfortunately end up using static data anyway, it seems like
it might be better (in a pragmatic sense) to just add an
lv2_lib_init(bundle_path, features) and lv2_lib_fini() and re-use the
existing lv2_descriptor().  That way we don't have two separate
discovery APIs and two separate lv2_descriptor functions... It certainly
doesn't look very nice to have both in lv2.h

-dr