[gmpi] Re: ABI's

Hi Tim, thanks for helping frame things for me.

On Tue, Feb 22, 2005 at 06:01:17PM -0800, Chris Grigg wrote: 
 What I don't understand from a practical perspective is, why are we
 talking about relying on other peoples' ABI specs in the first place,


I think the ABI talk is mostly about being compliant with existing
standards, which I personally don't think is important.

Jeff got the discussion into hot water by showing that for
*some*compilers* the C stubs are extraneous :)  I think we should keep
the C stubs.

Yes, I think this is where things get confused... when presenting the architecture, this should probably be put in happy-coincidence terms, e.g. "...(this happens to be binary compatible with MyFavoriteCompiler v.X.Y.Z)..." -- as opposed to inadvertently creating the impression this particular compatibility was an important design objective.


The API is C.  It is defined in C and is implemented in C.  Beyond that,
the SDK provides the glue to make it C++ (stubs).  The same could be
done from any language binding.

 1) Define a single, very simple function ptr table format for the
 start of all of GMPI plug package files, without referencing, nor
 claiming to be binary-interoperable with, any external ABI spec.
 Simple is the key.


This is where we are.  The continued references to COM should probably
be calmed down.  What we have tastes a lot like COM.  If you know COM,
you'll feel comfortable with GMPI.  That is and should be where it ends.


Well put.


For people who are not familiar with COM, there is a learning curve.
That would be true no matter what the API ended up being, so no harm
done.

I'm going to advocate that we drop the silly VTABLE_PREFIX.  It's purely
to stay binary compatible with Mac's COM implementation, and we're *not*
making COM objects.  Just a COM-like API.

Have to agree, plus the "VTABLE" in the symbol just plain risks confusion. If the host really really wants to use Mac OS X COM talk to GMPI plugs, then let it fake its own COM vtables -- IMHO that's plat-specific, inappropriate for the common code.


 > OK, going back to hide under my rock now...

Thanks for popping up. Does what I've said here seem reasonable? 

Quite, thanks for helping me sanity-check myself.  8-)

        -- Chris G.



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

Other related posts: