[gmpi] Re: 3.13 Persistence

On Fri, May 28, 2004 at 05:47:46PM -0700, Chris Grigg wrote:
> >This one is getting too "speccy".  Mind if I nix a few of the later
> >details?  I think the requirement is summed up well up to "A Bank file may
> >contain any number...".  The numbering and contiguity are not really
> >requirments, are they?
> 
> That's fine.  I'll try to remember to put them back in when we get to 
> the spec phase... in late 2009.

I'll also save it in my notes.  I have a lot of notes :)

> >Also, I disagree that it needs to be human
> >readable.  Instead, I'd say it needs to use existing technology, (such as
> >zip or tar).
> 
> I don't understand your motive then, as there's nothing editable 
> about zip or tar.  What are you really after?

I'm after a format that doesn't require special tools.  ZIP and TAR *are*
essentially editable, because *everyone* already has the tools needed.

If a preset is a single text file (such as XML or something), then making a
bank of presets is as simple as making a tarfile with all the preset files
and maybe a "manifest" file (which is the part I don't know for sure
about..).

Adding presets to a bank is trivial.  Copying presets out of a bank is
trivial.  Tweaking a preset is trivial.  None of those REQUIRE special
tools.

> >I also want to leave off anything that says it is optional.
> >I'd like to see the GMPI format become THE format for distributing
> >presets, so it's not really optional.
> 
> Well, I agree that would be a nice outcome, but good luck selling 
> that to the big host companies who already have their own ways of 
> saving session state data.  I'm suggesting making it optional as a 
> way of cutting to the chase.

Well, they can certainly keep doing things their own way.  But if we make
a GMPI preset/bank format easy enough, they'll WANT to include support for
it.  Better, plugin vendors should distribute their presets in the GMPI
preset/bank format.

I'd propose that "factory" presets be a GMPI preset bank, instead of built
into the plugin.

> >I'm no XML nut, but it makes a nice extensible format.  That said, I don't
> >care if it is XML or any other text-based format.  That's the requirement
> >- human readable. :)
> 
> Uhh... which side do you intend to argue?  8-)   Above you said you 
> .didn't. think it did need to be human readable...?

Sorry, ambiguous parse tree.  I don't care if it is XML or some other
format, as long as it is human readable with basic tools.  It doesn't HAVE
to be XML or even text, those are spec details.  Text is nice because we
ALL have text editors.  XML is nice because it is well-understood,
extensible, nested, and simple to parse.

I'm not tied to XML in any way.  It *is* buzzword compliant and I'd
probably argue against defining some other text format unless there was a
good reason.

> >At some point we agreed that the benefit was twofold:
> >1) ONE and ONLY ONE mechanism of saving/restoring state
> >2) human readable presets is a nice feature.
> 
> What if the plug decides to change its parameter set in the middle of 
> a state save?  How do you prevent that?

A good question.  Don't allow it?  Arrange it such that that can't happen?

> >Now, I don't think that the final preset format will ONLY be the
> >parameters, but will be some meta-data and probably some optional binary
> >blob header or something.  The main goal is to make a preset
> >hand-tweakable.
> 
> Then that should be explained in this section.  How would you put it? 
> What metadata?  Why the blob, what would be in it?

The blob would be added IFF the spec decided it was needed.  It might not
be.  Things I can see in there might be private info such as the
parameter-list structure.  But even that can be done as a hidden opaque
parameter.

Plugin authors who REALLY want to only save one big opaque chunk still
can.  They just have a hidden opaque parameter which is stateful.  All the
rest can be non-stateful.  We should, of course, discourage that.

> >I think the general rule should be that a plugin is always backwards
> >compatible with old presets.  If you need to break compatibility with old
> >presets, change the plugin ID.
> 
> Another possibility is that a plug could expose not just a single 
> plugin product ID, instead expose a list of the preset format 
> versions it can read.  In other words, the plugin ID is one 
> build-time plug property, but the 'compatible preset types' list is 
> another.  The plugin ID is used for most purposes, but the list is 
> used when figuring out what preset types the instance can access.

Something like that could work, but is there really an advantage?


----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: