[Devel] What is a feature? (extension_data)

[Stefano D'Angelo]

2011/11/1 David Robillard <d at drobilla.net>:
> On Sun, 2011-10-30 at 23:45 +0200, Stefano D'Angelo wrote:
>> 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...
>
> This'd be true if it was established and consistent, but alas, it's not.
>
> The reasons for wanting to properly clarify and define this is more of a
> documentation and "have things make sense" thing rather than something
> that will really affect practice in any way.
>
>> ... 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.
>
> In short:
>
> Problem: There is currently no way to declare in data that a plugin
> provides a certain extension_data.  Therefore, we need a property for
> this.
>
> Issue raised: What is the range of this property?
>
> This issue raises a bunch of similar/identical questions.  For example,
> if I'm going to declare an extension_data, I would need/want to document
> that in Turtle as:
>
> <http://example.org/mydatathing> a lv2:What .
>
> What is lv2:What?  Feature does not seem appropriate.
>
> In summary, we have no meaningful way to say things about extension_data
> whatsoever.  This is ungood.

Ok, now I think I got it. We need this because: 1. it's bad that the
host has to discover by trying which URIs the plugin will "respond to"
via extension_data(), and in some cases this could really make no
sense, 2. it would be good anyway to have this information for other
purposes (e.g., compatibility matrix documentation, as you suggest).

Well, in this case I think the lv2:HostFeature and lv2:PluginFeature
distinction + lv2:hasExtensionData now make sense to me, but I agree
this terminology is somehow confusing (and indeed, it did confuse me).

I don't think I am able to come up with anything substantially better,
but what about:

<http://example.org/mydatathing> a lv2:ExtensionDataURI .
<http://example.org/myplugin> lv2:supportsExtensionDataURI
<http://example.org/mydatathing> .

This to avoid overloading terms and keep the distinction between
lv2:Feature and the new thing. Otherwise, I don't really know if
subclassing lv2:Feature could result in stupid mistakes/easy
abuse/somehow worse situation...

Stefano