How about this:
1.) Plugins have a non-instance-based call GetVersion(), which returns
an integer version identifier.
2.) Plugins have a non-instance-based call GetVersionBehavior() which
takes a version number in and returns a behavior code out of the
following list:
a) VersionNotSupported. This means that the plugin cannot accept data
from the specified version. This could be simply because it is too old
to still have support, or it is an unrecognized future version.
b) VersionEmulated. This means that the plugin can behave identically as
if it were the version requested. Parameter lists will match the old
verison.
c) VersionEmulatedNoUI. This means that the plugin can behave
identically for rendering but cannot display custom UI for the version
requested.
d) VersionInterpreted. This means that the plugin does not actually run
the old data, but will accept it and transform it into the new data
format. In this situation, the plugin must support
ParameterInterpretVersion(), which takes a parameter value in with a
version number, and returns a parameter value in the new version space.
This could mean range changing, arb data rewriting, whatever. This way
the host does a one time pass on all of its saved data in the old
version and updates it to the new version data.
e) VersionIdentical. There is no host-visible change between the version
and no action needs to be taken.
The constructor for plugin instances then takes a version number of the
requested version to instanciate. For VersionNotSupported and
VersionInterpreted, and version number other than the current one
returned by GetVersion will fail.
Marc Poirier wrote:
Oh yes, copy protection (can't we just agree to disallow copy protection in GMPI? ;-)
Okay, well I personally have no objection to this idea as long as 1) it is definitely optional and 2) it's not considered the only way to support different-version state data. I think that the first expectation should be that the plugin will interpret the data, if possible, but if the plugin supports this old version emulation mode, then the host can choose to try that with the old state data (but if that fails, then the host would try seeing if the plugin might still be able to interpret the data). How does that sound (hoping that was at least coherent)?
Marc
--- Mike Berry wrote:
Well, I never thought that this would be a required feature of any plugin. But I think that it would be very cool to allow GMPI to support it, in order to allow users to not have to worry about keeping all of those old plugs lying around and figuring out how to get them reinstalled, particularly if there is also some kind of copy protection system associated with them as well.
__________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
-- Mike Berry Adobe Systems
---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
