[LAD] State of Plugin API's

[Stefano D'Angelo]

2009/11/1 Paul Davis <paul at linuxaudiosystems.com>:
> On Sun, Nov 1, 2009 at 4:59 AM, Stefano D'Angelo <zanga.mail at gmail.com> wrote:
>
>> To me this is nonsense, the best way to do that I can imagine is
>> assigning one bit position to each extension and sum them up to give
>> your <N>, but I can already imagine huge unreadable numbers (how many
>> extensions do we have now? 20?) and probably there's no better way to
>> do that.
>
> the idea is not to enumerate *all* extensions. it is to define a name
> for a particular rev of LV2 core plus a particular set of extensions.
> if there were 10,000 extensions but the generally accepted practice
> was to support 10 of them, what use would there be in somehow
> indicating support for any/all of the 10k via some kind of number or
> name?
>
>> This also clashes IMO with the idea of using URIs for decentralized
>> extension development (no, please, not unique ids again!)
>
> it clashes with it to the same extent as having "LV2 core rev 3" does.
> the "LV2-E<N>" designation isn't intended to define an extension, its
> intended to define a version of LV2, or, if you like, a standard for
> LV2, not just LV2 core.
>
> one example that springs to mind here is MMC. it didn't have
> decentralized development, but my understanding is that the process of
> specifying it effectively collected new commands and new state from
> just about every participant. rather than require that any
> implementation of MMC supported them all, or supported some random
> subset of them, they defined four "levels" of support. MMC Level 1 is
> a common core set of commands and state that any MMC device must
> support. Level 2 makes the spec a bit more useful. Levels 3 and 4 are
> really not that important unless you have a very specific type of
> device.

Sorry, I didn't really get what you were meaning then.

In this case it's surely possible, but would it really be much more
"readable" to use a number than to state the name of such extensions
or, even better, define sets of extensions as "levels"?

I mean, 10 extensions means numbers from 0 to 1023, and you have to
know binary arithmetics to make sense of which extensions are
supported... not very marketing friendly. Better to define "level 1",
"level 2", etc. IMO.

Anyway, since this does not affect LV2 as a specification, I just
really don't care. The one thing I would care about is how/which
extensions would belong to a certain standard/set, etc.

Best regards,

Stefano