On Sun, Nov 1, 2009 at 4:59 AM, Stefano D'Angelo <[email protected]> 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. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
