[LV2] Add/remove/change ports from practical view ?

[David Robillard]

On Wed, 2020-05-27 at 08:24 +0200, Sven Jaehnichen wrote:
> Hi,
> 
> I know that lv2core tells that
> * Change of a port lv2:symbol, or
> * Remove of a port, or
> * Addition of a port unless it is lv2:connectionOptional
> breaks compatibility (both, forward and backward) and requires a new 
> major version number and thus a new URI for the respective plugin
> (see 
> http://lv2plug.in/ns/lv2core#minorVersion).
> 
> On the other hand I (and others) experienced that the most (if not
> all) 
> hosts are tolerant about additions (even without 
> lv2:connectionOptional). Unless it is an unsupported feature. Also 
> deletions seem to be possible. Only changing the lv2:symbol of a port
> is 
> EVIL (and this makes sense).
> 
> Are there any know *practical* problems about the addition of 
> non-connectionOptional ports

If a new port is not connectionOptional and the host does not know its
type, then it would not be able to connect it to anything.  That's the
reason for that rule, but I agree this one could maybe be relaxed.  I
can't think of any serious practical problem that is likely to happen
there, other than the plugin possibly not working anymore depending on
what the new port is like.  If it has the same type/etc as previous
ones though, that shouldn't happen though (perhaps this should be a
hard rule?).  Adding stuff is generally fine in a traditional semver
sense.

I'm open to this relaxation if nobody else has a problem with it.  From
an ultra strict perspective it's breaking the spec in that hosts would
be required to deal with a new situation, but it doesn't seem like one
that should cause much trouble, and in practice probably already
doesn't as you noted.

> or the remove of *unused* ports? I ask 
> because I have some of such *unused* ports.
> 
> For the case that this is only a theoretical problem, wouldn't it be 
> possible to be less strict (now: capitalized MUST) about addtitons 
> and/or deletions?

Removal is much more problematic.  Why would an "unused" port ever have
existed at all?  This seems like a pretty esoteric case to me.  What
unnused ports do you have?  It seems like a pretty strange thing to put
in the spec to me, since plugins shouldn't have had any unused ports in
the first place.

The main problem with removal is that there might be settings or
automation for the port that significantly affect the sound and
removing them means that the host now has this data that doesn't make
sense (because it corresponds to a non-existing port) which it needs to
do something with, and from a user POV it could "break" their
song/session/whatever in the sense that their
settings/recording/whatever is effectively gone.

A more programmer-ey example than automation and stuff to think about
is script bindings.  If a plugin had a "gain" port, and I was using
nice script bindings and had some script that did plugin.gain = 60,
what happens when there is no gain port anymore?  A crash, probably. 
That's not good.  Just as with libraries, compatibility matters for
plugin interfaces.

Plus, if you can remove ports, and you can also add new ports, then you
can rename ports, which opens up breaking sessions in all kinds of
ways.  In general such rules exist because this stuff is actually
important, even if some plugin devs don't care about breaking things
for users and just find it annoying.  I think a better way to address
this is to have a good standard mechanism for stating that a new major
version (i.e. plugin with a different URI) is an evolution of an old
one.  Depending on the how complex that mechanism is, that could mean
that you could *actually* rename ports safely without breaking
everything, which seems a lot better than "sure just break stuff
whenever and don't even give hosts a way to deal with the situation"...

Cheers,

-- 
dr