[LV2] Dynamic manifest URIs and CAPS' strange case

[Stefano D'Angelo]

2013/2/2 David Robillard <d at drobilla.net>:
> On Fri, 2013-02-01 at 23:48 +0200, Stefano D'Angelo wrote:
>> Hi all,
>>
>> Next NASPRO release is coming soon, no new features, just small fixes
>> here and there.
>>
>> Anyway, I still have two potentially tricky things to sort out. The
>> first is whether it matters if I change URIs of dynamic manifests (not
>> bridged plugins, just the dman:DynManifest). The problem is that
>> NASPRO is not part of Atheme anymore and that is also reflected by the
>> website having been moved to sourceforge. Hopefully nobody is
>> hardcoding the old URIs.
>
> I would be quite surprised if that's the case and changing the URI of
> the DynManifest breaks anything.

That's the same thing I thought. If nobody else will complain in
reasonable time, I will just change them.

>> Secondly, and probably more importantly, I have the feeling that the
>> new CAPS release keeps the old LADSPAs unique IDs but breaks port
>> signatures. This sucks, I remember me and David suggesting the author
>> not to do it, but still he seems to have done it. This means current
>> bridges are propagating the breakage into LV2 land. Which sucks even
>> more because it explicitly violates LV2 rules. Now, probably the best
>> thing to do would be to special case CAPS and try to detect whether
>> it's the new or old version being bridged and use new URIs for the new
>> plugin set (something like urn:ladspa:caps-new:XXXX?). However, it
>> might happen again in the future, I guess. Any suggestions?
>
> Honestly I wouldn't bother.  While this sucks, and if true is a very bad
> move whether you consider LV2 or not, I don't think NASPRO should
> attempt to add layers upon layers of compatibility kludges for specific
> plugin sets.  If anything not having the straightforward URI mapping any
> more would probably cause even more difficulties.
>
> Assuming this is a problem, i.e. the port signatures have changed
> incompatibly, that breaks existing sessions for LADSPA supporting hosts,
> too.  They broke in LADSPA, and they will consequently break in LV2.  A
> shame, but an unavoidable one.  Particularly since no hosts that I know
> of actually implement any kind of graceful compatibility break tolerance
> for LV2 plugins, I would say the expected behaviour is to simply wrap
> the LADSPA, and worrying about this is not worth the effort.
>
> Since LADSPA authors are likely to just blame LV2 as an easy out, it's
> probably more effective to argue based on LADSPA host sessions anyway.
> For example, if you had an Ardour session that uses that plugin, that
> session is now broken.  This is a very bad thing.

The lazy part of me was suggesting the same, actually. Anyway, this
leads to another smaller issue: what should I do with the manually
edited LRDF-equivalent data? Update it to the new CAPS releases and
thrash the old data? Only update the new stuff? Drop all LRDF-like
data for CAPS? Currently I am going with the second option, but any
change is quickly done.

Stefano