[gmpi] Re: 3.13 Persistence
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 28 May 2004 15:00:18 -0700
It's time for topic #3.13 - Persistence.
Have at it:
http://www.gmpi-plugins.org/gmpi/requirements.php#sec_3.13
Tim
Hi --
Sorry for the lag, I was vacationing (mid-Pacific, far too bright for
LCDs). 8-)
I think the meaning of the text is fine, but the nouns should be made
more consistent. Plus a little grammar fixing. And I think we should
have more specificity about the purpose and organization of the
files. Also I think the state definition concepts should come first.
So... can I suggest?:
"Req 59: The plug-in's state is defined to be the collection of
its stateful parameters' values. Every parameter is either stateful
or non-stateful (this parameter property may not change over the
plug's lifetime), and GMPI must define a mechanism for the host to
determine this for each parameter. <<Should this idea also be
reflected in the Parameters section?>>
Req 60: For a host to save the state of a plugin, it simply queries
all the plug's stateful parameters and saves them somewhere.
Likewise, to restore the state of a plugin, a host simply sets all
its stateful parameters to the stored values.
Req 61: GMPI must define a simple file format for storing plugin
state, for use both in user preset libraries and GMPI graph
save/restore. Such files are called Presets. A Preset file must
include the values for all of a plug's stateful parameters, therefore
completely describing the plug's state. The format must also
indicate what plugin (manufacturer, product, and product version)
provided the data. For GMPI graph save/restore, it is up to the host
to keep track of what plugin instance the state represents. The file
format must be human-readable and editable with an ordinary text
(incl. Unicode) editor. Host usage of this file format is optional.
Req 62: GMPI must define a simple file format for storing user
libraries of Presets, probably based on the Preset file format
described above. Such files are called Banks. A Bank file must also
indicate the plugin product (manufacturer ID, product ID, and product
version ID) that provided the data. A Bank file may contain any
number of Presets. Within a Bank, each Preset may be named, and must
be numbered. Preset numbers must be unique but need not be
contiguous. The file format must be human-readable and editable with
an ordinary text (incl. Unicode) editor. Host usage of this file
format is optional."
ALSO ---
All the above goes along with two design decisions I'm not actually
all that crazy about:
1 - Specifying XML as the preset/bank file meta-format is OK for
computers, but not necessarily so good for tiny devices; depends on
whether the DTD is close-ended or open-ended (open-ended is way
bigger/harder to implement, close-ended is probably fine).
2 - I don't understand why we make the host query every plug for its
parameters and then query state on each one of them, when we could
just require the plug to provide one big Preset parameter. Very
modest impact on plug authors, IMHO.
3 - In a Bank, what if there are different product versions? Can
their Presets still go into the same Bank file? Put the other way
around, how much need to be in common for a preset to be allowed into
a given Bank? We need to take product renaming, cross-compatibility,
etc. into account here.
-- Chris G.
----------------------------------------------------------------------
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
Other related posts:
