Pierre, just to be clear, these are errors that the plugin can return to the host from kOfxImageEffectActionDescribeInContext, right? I don't think it matters what error codes are used; the host shouldn't care (it won't do anything differently). So standardizing on kOfxStatErrUnsupported for this case makes the most sense to me.
Documenting Expected Behavior when an effect does not want to get loaded in an host.version Proposed
Standard version: 1.4.1
Minor Change
Stephen Bash (Genarts), seconded by Pierre Jasmin (RE:Vision Effects)
There can be multiple reasons for a plugin not wanting to get loaded in an host.version. For example the plugin might depend on a feature not supported by an host (e.g. a camera suite)
It is suggested that the OFFICIAL way of doing this would be to simply not support any context and return StatDefault.
This needs to be clearly documented somewhere so effect developers are aware of this.
Document clarification: to make kOfxStatErrUnsupported what to document to return when you cannot or don’t want to load a particular plugin in an host.
-> Proposal is to add to documentation that returning kOfxStatErrUnsupported from DescribeOnContext means to silently not use the plug-in. We could also clarify that if a host does not support any of the contexts that the plug-in offers then it also would not use the plug-in.
Discussion
Comments
We could document a list of valid error messages during initialization:
kOfxStatErrMissingHostFeature
kOfxStatErrUnsupported
which should prompt no host action (not load plugin, not report to users it could not load, not pretend it did not happen...)
Another solution would be from v1.5 to state that a plugin could simply whatever we decide is the right error message (e.g. kOfxStatErrUnsupported) and document the safe way and backward compatible way is to implement support for no context.
I am OK with documenting kOfxStatErrUnsupported as the chosen one