[Devel] What is a feature? (extension_data)

[David Robillard]

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> .

-dr