> First of all, I certainly hope that plugins will publish their version, > and that that will be a required part of the API. > I don't mind that. > Secondly, I also hope that the state data format, when we get there, > includes version, whether it's done as a "parameter" or not (and > personally I don't see why it would be one, it's not changeable). Exactly. But the idea of a state data format itself negates being able to recall a state only by its parameters, doesn't it (which is what started my comments)? > Thirdly, what difference does it really make if you publish a parameter > that is arbitrary data, even if it's something secret or something like > that? Only the plugin knows how to understand it, and can provide an open > way for the user to alter it or not. Not much of a difference. Only, a host will be more complex if it has to distinguish between understandable parameters and others (since obviously it can't show the others to the user). > What's the real crux of your > concerns here? Backward compatibility in a plugin. Right now, I save a version number in the state of a plugin. Then when I read it back, I know how to make sense of that data. > Fourthly, I think that it should be possible for GMPI plugins to mark some > parameters as private or whatever you want to call them, basically things > that should not be shown in generic interfaces. Yes, that's a possible solution. But once again, that just puts more of a burden on the host, while I think that a plugin should be free to save its data exactly the way it wants to. Frederic ---------------------------------------------------------------------- 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