Is there a way to declare a plugin obsolete to the host app?

[scritturamista]

Going through the headers and docs, I couldn't find a property to declare a plugin obsolete.

This is a common concept in other VFX SDKs. The purpose is to allow shipping a new version – which is obviously advertised in the UI – while bundling previous versions of the product for compatibility reasons.

To be clear: this is a boolean that tells the host app the plugin should be hidden in the UI for the purpose of adding new instances. The plugin should remain usable by the host app in order to support existing uses of the plugin, e.g.

/** @brief Indicates whether the plugin should be hidden in the UI while remaining fully functional where it had been previously used

   - Type - int X 1
   - Property Set - plugin descriptor (read/write)
   - Default - 0
   - Valid Values - This must be one of
       - 0 - which means the plugin is the current version, and should be advertised to the user
       - 1 -  which means the plugin should not be advertised to the user in the effect browser UI

*/
#define kOfxImageEffectPluginPropObsolete "OfxImageEffectPluginPropObsolete"

Did I miss anything?

Thanks!

[fxtech]

Looks well-defined to me.

[barretpj]

I think it needs a little more documentation to try to avoid it being used incorrectly by a plugin vendor.

• the plugin should not be advertised to the user if there is a newer version (based on major.minor version numbering) also installed

and/or

• this property should only be set when there are multiple versions of the same plugin contained in the same bundle. At least one version (typically the newest) must have kOfxImageEffectPluginPropObsolete set to 0.

[fxtech]

I've run into something like this before, where we had an old node that did task X, but it was replaced by a different node that handled task X in a different, but better way. In order to encourage users to use the new node, we marked the old one as obsolete so it didn't show up any more, but it would continue to work if a project was loaded that used it. So I don't think we need a requirement that at least one node in the bundle have obsolete=0

[barretpj]

Just trying to avoid customer disappointment when they install a plugin and nothing shows up in the host UI because everything they've installed is marked as obsolete.

[scritturamista]

Just trying to avoid customer disappointment when they install a plugin and nothing shows up in the host UI because everything they've installed is marked as obsolete.

I would imagine that the developer/company is in charge of avoiding this. If you ship an installer that places multiple versions of the same plugin on the system, it would seem natural that one of them (and only one of them) would be the non-obsolete one.

the plugin should not be advertised to the user if there is a newer version (based on major.minor version numbering) also installed

I would instinctively be against the host app trying to be smart about hiding previous versions. There are legitimate reasons a company may not want to take advantage of the "obsolescence" mechanism. Let’s compare the two simplest scenarios:

• The new version of a plugin is a free update and as such there are no barriers to the upgrade for existing users. The author/company is keenly interested in having users adopt the new version as fast as possible, perhaps because of bug fixes or important new features. This is where the obsolete flag really helps.
• The new version of a plugin is a paid upgrade, and in order not to upset customers who have decided not to upgrade, the author/company is still providing download links for installers to the previous version. At the same time, said customer may have the trial version of the new version. If the host app decided that the paid versions should be automatically hidden based on comparing version numbers, it would create a tech support incident.
• Regardless of whether the new version of a plugin is paid or free, an author/company may have legitimate reasons to allow users to keep two versions side by side. The customer may be working in one of those "we don't touch / upgrade anything until the project is done" settings, and as such might need access to an older version even after installing the new one.

Bottom line: the author/company alone should declare a plugin obsolete.

[barretpj]

I'm coming from the host vendor perspective, and I know that if a customer installs a plugin and it doesn't show up in the UI, they will report it to us as a bug in the host. And we will have to spend time diagnosing why. So I want the documentation in the header file to make it clear to all plugin developers what the best-practice recommended use of this flag is.

I would imagine that the developer/company is in charge of avoiding this. If you ship an installer that places multiple versions of the same plugin on the system, it would seem natural that one of them (and only one of them) would be the non-obsolete one.

Yes, that's what I want to made explicit as in the comment documentation.

[scritturamista]

Yes, that's what I want to made explicit as in the comment documentation.

I would hope the developer would come to that conclusion even without a warning :-) but spelling it out can't hurt.

[fxtech]

I guess my point is I don't think it's up to the host to enforce this. If I find an obsolete plugin and the new, non-obsolete one "didn't get installed somehow", am I really meant to show the obsolete one anyway?

[scritturamista]

I guess my point is I don't think it's up to the host to enforce this. If I find an obsolete plugin and the new, non-obsolete one "didn't get installed somehow", am I really meant to show the obsolete one anyway?

I'm in agreement on this point. Impossible and unnecessary for a host app to predict all possible configurations and reasons. My best guess is that a host app that tries to second guess the user or developer would simply create edge cases that would be hard to diagnose on tech support.

Just a friendly sentence in the header explaining why you’d need the flag should be enough.

[scritturamista]

I don't want to immediately break etiquette, but looking at the requirements for a PR, they seem just a tad overkill for something like this. Any recommendations? How would I recruit the "vendor" and committee members?

[barretpj]

I don't want to immediately break etiquette, but looking at the requirements for a PR, they seem just a tad overkill for something like this.

They're not overkill, we want to ensure every change has actually been used and tested in a real plugin and a real host before it gets published.

How would I recruit the "vendor" and committee members?

You can ask here, or on the ASWF Slack #openfx channel.

[scritturamista]

Thank you! As far as naming convention goes, is there any reasoning behind property names? I couldn't quite understand if kOfxImageEffectPluginPropObsolete or simply kOfxImageEffectPropObsolete would be appropriate. Is the inclusion of "Plugin" based on whether the property is readable/writable for plugin descriptors vs plugin and instance descriptors, for example?

[barretpj]

As far as naming convention goes, is there any reasoning behind property names? I couldn't quite understand if kOfxImageEffectPluginPropObsolete or simply kOfxImageEffectPropObsolete would be appropriate. Is the inclusion of "Plugin" based on whether the property is readable/writable for plugin descriptors vs plugin and instance descriptors, for example?

It's far from consistent, I think the usual meaning is whether it's only ever a plugin property, or if it's a more general thing like kOfxPropLabel which can be used elsewhere in a property set describing something other than a plugin.

[fxtech]

I like the more concise kOfxImageEffectPropObsolete. It matches the other ImageEffectProps. I can get this into Silhouette and send you a custom build to test with if you like.

[scritturamista]

@fxtech That is kind of you! I'll come back to this when ready. In my limited experience with OFX I have accumulated a long list of small feature requests, mostly gaps in the SDK that come from "diffing" with other SDKs I'm more familiar with. It seems the best approach is to create a branch with all these small changes and reuse that same branch for multiple PRs, each with its separate testing procedure but ultimately (and hopefully) with a single test plugin to work with.

[garyo]

@scritturamista it's best for each PR to be separate, for us; that way each can be tested with plugins and hosts independently, we can discuss them and get them merged in cleanly.

[scritturamista]

@garyo I should have been clearer: yes each change will be a separate PR, but is it OK if they are all off of main, or do you prefer every change on its own feature branch?

[garyo]

It's easier if they don't depend on each other, because we can be slow :-) but we'll make it work however you do it.

[barretpj]

And remember that OFX is not an SDK. It's just a set of header files, documentation, and some sample code. Adoption of any changes is always slow and patchy for both hosts and plugins. Plugins will have to handle hosts that don't implement new functionality, and hosts will have to handle plugins that don't implement new functionality.