[LV2] Inheriting plugin properties

[David Robillard]

On Sat, 2013-06-29 at 14:45 -0400, David Robillard wrote:
> On Tue, 2013-06-25 at 08:15 -0500, Michael Fisher wrote:
> > On Sun, 2013-06-09 at 16:03 -0400, David Robillard wrote:
> [...]
> > > The problem is the binary.  Currently, Ingen saves a symlink to the
> > > 'system' ingen_lv2.so, which works locally, but is obviously a problem
> > > for distributing patches.  What's needed is a way to specify that the
> > > binary for this plugin is the same as the binary of some other plugin
> > > (e.g. a template the user must have installed)
> [...]
> > I think something like this would be useful indeed.
> > 
> > What about inheriting the plugin as a whole:
> > <>
> > 	a <my_plugin_uri> ;
> > 
> > Then just override properties as needed.  Not sure if the above even
> > makes sense in RDF/Turtle land.
> 
> Not literally, since a plugin is not a class.  We could invent
> vocabulary for doing this though.
> 
> I'll have to think about this one, not sure if this is too 'aggressive',
> would cause problems, or is too much of a host burden (though in
> practice that's lilv's problem anyway).  I suppose this would be quite
> useful for sets of plugins that are all very similar to avoid having to
> list all the same data many times, which would be quite nice...

More thoughts on this: override is effectively impossible, since
properties can have several values.  The only way this would be doable
is to require all properties to be fully documented (e.g. with
cardinality) and hosts to use this information, much too complex.
Alternatively we could add special vocabulary for replacing properties,
but this is also quite complex.

Thus, the realistic/KISS approach for this is for the 'template' to have
to have ONLY properties which will be on the plugin.  The plugin
description could add properties, but not remove or replace.

This means you couldn't 'inherit' from an actual complete plugin
description, but given the alternatives I don't think that's a big deal.
This facility would be for explicitly factoring out common things, not
extending plugins.

-dr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20130630/2fbbd68b/attachment-0002.pgp>