[Devel] What is a feature? (extension_data)

Stefano D'Angelo zanga.mail at gmail.com
Sun Oct 30 14:45:45 PDT 2011

2011/10/29 David Robillard <d at drobilla.net>:
> On Sat, 2011-10-29 at 16:19 +0300, Stefano D'Angelo wrote:
>> 2011/10/28 David Robillard <d at drobilla.net>:
>> > The current release of LV2 has some confusing comments about
>> > extension_data.  It's not really clear just what a "feature" is, and how
>> > the plugin data would indicate that the plugin provides some
>> > extension_data (despite the comment saying that they must).
>> Do we actually need that the plugin data says anything about
>> extension_data being not NULL/doing anything useful? Anyway, I can't
>> find the comment you are referring to...
> For some value of "need", yes (at the very least it's useful to know
> what plugins support what), but it's not critical like for features
> passed to instantiate (i.e. it's not really so bad to use
> extension_data() as a discovery mechanism for these)

Well, it seems like extensions define how to use it now, but...

>> However, I have checked the current extensions on lv2plug.in and the
>> only ones making use of extension_data() are persist, data-access and
>> ui-resize that uses the equivalent extension_data() for UIs. Now, in
>> all of these cases I don't think it's really possible to determine
>> whether a feature is a host feature or a plugin feature, to me it
>> looks it's always somehow a combination of the two, and also I see no
>> need to make such distinctions.
> There has been an unfortunate history in the past of using extension
> URIs themselves as feature URIs.  This was a very bad idea (extensions
> could have several features) and isn't the way things will be done from
> now one.  Event is the most obvious example of why this is wrong.
> I am more interested in how it should be than trying to classify past
> behaviour.  Past behaviour is inconsistent, that's the problem.

... the point is: I can see what has been done but I cannot read your
mind and see what you want to do. :-)

So I'd say, with the limited amount of knowledge I have, I don't
really understand where is the problem.

>> P.S.: for the record, I think there is at the very least some overlap
>> with the LV2_Feature array in instantiate(), I guess we could just
>> have avoided having extension_data() in the first place.
> Huh?  The LV2_Feature array is the the host passing things to the
> plugin, extension_data is for the plugin returning things to the host.
> Pretty clear distinction.

Well, this is not important now (too late), but what I wanted to say
is that we could just have some negotiation going on in instantiate
without needing extension_data at all.

More information about the Devel mailing list