Perhaps, this is coming in from far left field, but has anyone given any
thought to a middleware product like ICE (zeroc.com)? Ice is pretty darn
fast (probably not quite as fast as realtime Corba), but certainly should be
a feasible approach presuming that GMPI is not likely to come online big
time for a couple of years anyway. Once the object models are built in Slice
IDL it should be portable to any platform, though limited to langauages C++,
C#, and Java. Some folks are trying to get zeroc to port to Python and
Delphi as well, but I doubt they would ever consider a C port. The ICE
runtime is smart enough to avoid the network layer when communicating
between objects (by proxy) in the same proc space. Of course, you can also
communicate to them directly (not by proxy) and avoid delegating through the
ICE runtime as well if those plugs are in the same proc space. Also
something interesting about ICE (which I haven't really delved into
completely yet), is facets. Facets give some amount of versioning
control/extensibility though I do not know if it is quite as powerful as
COM's interface discovery capability.
The unforunate thing about ICE is that it is not exactly open source, it is
open for open source projects (or internal ones) but a license is required
for commercial closed source products. But... as long as the GMPI effort
remains open source I think licensing could be avoided? In addition, using
an ICE object model opens up a lot of doors for a distributed system!
Also, in regards to Ron's question about close sourcing GMPI, making
involvment require an MMA stipend and finally moving the development to a
members only server. I personally would be sad to see that happen. I have a
non-commercial interest in GMPI but like to think I could still provide some
useful ideas in its development (perhaps every blue moon).
Regards, Ryan Fogarty
In my view the API should be written first as a set of COM interfaces, then
these can easily be translated into object-oriented C.
Indeed, if the API is defined as a COM coclass in Visual Studio, then the
Microsoft compiler will automatically generate C calling convention
declarations for the class. I would imagine that the generated code could
be ported to other platforms without too much trouble. The Microsoft macros
can simply be expanded into their ANSI C source and any Microsoft-specific
system calls can be removed or abstracted.
There might be something similar in Mozilla XPCOM, which is by design cross-platform.
Then we can have an object-oriented design that is callable from any C calling convention binding. It would be simultaneously COM, C++, and C.
Please note, I do not recommend taking on all the baggage of COM. I want a plain C style interface. This is just a convenient way of getting an object-oriented one. It enables us to focus on the class design.
Original Message: ----------------- From: Frederic Vanmol frederic@xxxxxxxxxxxxxxx Date: Wed, 2 Feb 2005 13:03:46 +0100 To: gmpi@xxxxxxxxxxxxx Subject: [gmpi] Re: NAMM follow-up, some major decisions to make
Also bear in mind that, given a sufficiently clean pure-object API, it's relatively easy for automated tools to produce bindings and glue for different languages and ABIs.
Trouble is it's very easy to get cross-language compatibility wrong with an
object API and very easy to get it right with a procedural API.
Frederic
---------------------------------------------------------------------- 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
-------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .
---------------------------------------------------------------------- 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
