1 Nov
2009
1 Nov
'09
7:53 a.m.
2009/11/1 Paul Davis <paul(a)linuxaudiosystems.com>om>:
On Sun, Nov 1, 2009 at 4:59 AM, Stefano D'Angelo
<zanga.mail(a)gmail.com> wrote:
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
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.