[Devel] What is a feature? (extension_data)

[Stefano D'Angelo]

2011/11/1 David Robillard <d at drobilla.net>:
> On Tue, 2011-11-01 at 09:18 +0200, Stefano D'Angelo wrote:
>> 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).
>
> Right.  Also, unfortunately, there are currently released plugins (swh)
> that crash when you call extension_data at all :(
>
>> 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...
>
> Yeah, I think I agree.  It's unfortunate the term "extension_data" is a
> bit crap, but oh well.  I think I will use this, but slightly tersified:
>
> <http://example.org/mydatathing> a lv2:ExtensionData .
> <http://example.org/myplugin> lv2:hasExtensionData
> <http://example.org/mydatathing> .

Ok.

I was also thinking that however there should be some note in the new
spec saying that this is a newly introduced thing, so older plugins
might still support some extension_data() stuff without explictly
saying in the RDF data. I.e., required for new plugins on a
please-be-nice-and-do-that-cause-in-the-future-will-be-strictly-required
basis, at least at this stage.

Stefano