I'm interested in this, but without broad host support this is kind of worthless.
Currently, entry points need to be unique. For example, multiple plug-ins in the same binary cannot use the same main entry point. Similarly, any custom parameter interact, each parameter needs it's own entry point. This makes it difficult to wrap the plugin API with generic support code.
The reason for this is that there is no information passed back to a plug-in from the host, which allows it to know which object to dispatch the action to.
All calls to an entry point need to convey information as to which object of what type the action should be dispatched. To this end, We need two extra properties…
kOfxPropActionDispatchObject - a one dimensional pointer property that is the object to dispatch to, what this is depends on the kOfxPropActionDispatchType property.
kOfxPropActionDispatchType - a one dimensional string prop that identifies what the action is being used for. This will depend on the API being implemented, but for image effects, this will only be one of three values…
“OfxActionDispatchMainEntry” - the entry point is being called as a main entry for a plug-in, the corresponding kOfxPropActionDispatchObject will be a pointer to the OfxPlugin struct passed to the host by the OfxGetPlugin function.
“OfxActionDispatchParamInteract” - the entry point being called is one set on the kOfxParamPropInteractV1 of a parameter descriptor. In which case the kOfxPropActionDispatchObject will be the handle of the parameter descriptor which set the interact.
“OfxActionDispatchImageEffectOverlayInteract” - the entry point being called is one set on the kOfxImageEffectPluginPropOverlayInteractV1 property of an image effect descriptor. In which case the kOfxPropActionDispatchObject will be the handle of the image effect descriptor which set the interact.
In general, where a main entry point can be set, then the type and object need to be specified.
Plug-ins that don't reuse an entry point can safely ignore these properties.