[LAD] State of Plugin API's

[Paul Davis]

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.