Standard version: 1.4.1
The API is meant to be called in a parallel manner, so that a host application may call actions on a plugin from any number of threads and have the API work. The only constraint on a plugin is that any calls back to the host via a suite must be from the thread the initial action was invoked from.
This problem arises when a host calls actions in parallel. It may have some private data specific to the context if the action it called the plugin in. Without that context specific data, the call back to the host is impossible to compute.
Given the calling constraint on a plug-in, the only way a host can pass itself back any private data is to place it in thread local storage. This is somewhat painful, especially as the suite function called may trigger recursive actions back to the plugin.
We amend the function signatures of a subset of suite calls to take an extra argument. This would be the inargs property set handle passed into the action. The host can decorate the underlying host-side structure behind that handle with the context specific data it needs, so when the plugin passes back the inargs via one of those suite calls, the host can access it's needed private data and determine what it needs to do.
This would possibly remove the constraint on plugins as to which thread they can call suite functions on.
(sept 23, 2016): This is near approved (approved enough for all new suites and versions to follow).
Note: It might not be important for MessageSuite and ImageEffect suite itself might be more a basket than the other suites and it would be occasion to fix incorrectly typed variables – which makes it even more a basket. Versioning ImageEffect suite itself, brings the next topic as well since it would probably only make sense if that suite was incremented.
Mini action item: We probably need a volunteer to think about how we would change type to what they should be without causing too much harm, as it implies versioning some #define… so the consequences can be evaluated..