[gmpi] Re: SDK/API model simplification
- From: jeffmcc@xxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 17 Apr 2005 11:51:12 +1200
Hi Tim,
> I'd like to short-circuit all these QueryInterface calls.
Then you lock us into 'forced backward compatibility'. I'll
explain...
With a COM-like system, each component (the plugin, the
host) is represented by an interface.
Think about GMPI version 2. Your assumption is that V2
will be a superset of V1, i.e. that a GMPI_Plugin2 supports
all methods that a GMPI_Plugin1 does. That's not the most
flexible approach.
Imagine we make a design mistake in GMPI V1, or find a
better solution to a requirement, or perhaps want to upgrade
a method to use, say, 64 bit arguments. With
QueryInterface, you are free to add, remove, or change an
object's methods. This gives us much freedom.
On the other hand, your proposal to restrict future plugin
APIs to simply extending V1 is a lot more limiting. VST
does that, each new version of VST has added more
functionality, but has not retired obsolete functions, the
result is somewhat over-complicated and unweildy, and
bug-prone.
QueryInterface futureproofs GMPI.
Queryinterface is at the lowest level of the GMPI
'plumbing', if you look at the example plugin code, you
don't see the COM stuff, it's hidden, GMPI plugin coders
seldom have to deal directy with it, therefore there is
little benefit to removing QueryInterface.
Best Regards,
Jeff
> Either everyone is too busy for this, or no one is left
> who cares.
>
> I'm going to ramble for a bit. If I don't get some
> feedback, I'm just going to do whatever the heck I want,
> and none of you will have any position to complain about
> it. Ok?
>
> Great.
>
> Now that we have a good chunk of code, using a COM-like
> model, I want to propose simplification. I'm already
> getting bogged down in a lot of the structure-version crap
> that QueryInterface seems to require (or maybe I am just
> mis-interpreting it all).
>
> Currently, the process of loading a file is something
> like:
>
> Host: read meta-data
> - find DLL for plugin ID
> Host: load plugin DLL
> Host: call DLL's GMPI_GetFactory(), store as an iunknown
> Host: call QueryInterface(IGMPI_Factory) on the iunknown
> Host: call factory->CreatePlugin(plugin ID)
> Plug: return plugin object
> Host: receive the plugin object as an iunknown
> Host: call QueryInterface(IGMPI_Plugin) on the iunknown
>
> Now, you add a host object into the mix:
>
> Host: read meta-data
> - find DLL for plugin ID
> Host: load plugin DLL
> Host: call DLL's GMPI_GetFactory(), store as an iunknown
> Host: call QueryInterface(IGMPI_Factory) on the iunknown
> Host: call factory->CreatePlugin(plugin ID, host object)
> Plug: store the host object as an iunknown
> Plug: call QueryInterface(IGMPI_Host) on the iunknown
> Plug: return plugin object
> Host: receive the plugin object as an iunknown
> Host: call QueryInterface(IGMPI_Plugin) on the iunknown
>
> None of this even explores the refcounting going on.
> I'd like to short-circuit all these QueryInterface calls.
> Something like:
>
> Host: read meta-data
> - find DLL for plugin ID
> - read DLL's GMPI_VERSION compat list
> Host: load plugin DLL
> Host: call DLL's GMPI_GetFactory(highest common
> GMPI_VERSION)
> Host: call factory->CreatePlugin(plugin ID)
> Plug: return plugin object
>
> The general idea is that the host chooses the greatest
> GMPI_VERSION that is common to host and plugin, and tells
> the plugin "use this version" of the GMPI api. From that
> point on, all the structures are assumed to be compatible
> with the GMPI API of the specified version.
>
> We can still taste like COM. QueryInterface() is used to
> check for optional interfaces. AddRef/Release are still
> used for refcounting. We're just tossing out one area for
> a lot of screwups. Simpler is better, and I don't think
> it imposes any hard restrictions (correct me if this is a
> bad assumption).
>
> While we're simplifying, can someone remind me why GUIDs
> matter? We don't really need a globally unique ID for
> every plugin, do we? Within any GMPI installation, you
> already can have unique IDs that are simpler and more
> meaningful: the path to a DLL file and an index code
> within that DLL file. We need all this information anyway,
> and it is guaranteed unique on a system...
>
> What think? I actually want to do some coding on this
> project. I'm just asking for opinions. If I don't get
> good discussion going within 48 hours, I'm going to just
> start hacking. If you can't make time for this project,
> that's fine. I can.
>
> Tim
>
> ----------------------------------------------------------
> ------------ 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
>
----------------------------------------------------------------------
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:
