[gmpi] Re: SDK/API model simplification
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 17 Apr 2005 22:37:05 +0200
On Sunday 17 April 2005 21.51, Tim Hockin wrote:
[...]
> As long as your plugin is compatible, use the same GUID. If you
> break compatibility, change it. The metadata certainly needs a
> version field, anyway, so you can have two plugins with the same
> GUID and different version fields.
>
> I guess the host needs to track (GUID, version) tuples to identify
> which plugin to instantiate.
Yeah, that's what I was thinking... I don't really like the idea of
having to deal with both GUIDs and versions, but OTOH, anything
seriously useful will have to look something like that anyway. The
GUID is just a much better way of dealing with that unique ID part.
Anyway, if we decide to do it this way, I think it's pretty important
that hosts really *do* consider the version fields part of the unique
IDs for this to work - or Very Bad Things(TM) may happen if a user
decides to install multiple versions of a plugin with the same GUID.
(There could be various reasons why a user wants to do that; bugs,
different sound in certain situations etc.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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
- References:
- [gmpi] SDK/API model simplification
- From: Tim Hockin
- [gmpi] Re: SDK/API model simplification
- From: David Olofson
- [gmpi] Re: SDK/API model simplification
- From: Tim Hockin
Other related posts:
- » [gmpi] SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- » [gmpi] Re: SDK/API model simplification
- [gmpi] SDK/API model simplification
- From: Tim Hockin
- [gmpi] Re: SDK/API model simplification
- From: David Olofson
- [gmpi] Re: SDK/API model simplification
- From: Tim Hockin