[gmpi] Re: NAMM follow-up, some major decisions to make

  • From: "gogins@xxxxxxxxxxxx" <gogins@xxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 2 Feb 2005 16:42:44 -0500

I would oppose this because of the license. We would want to make a usable
reference implementation.

Original Message:
-----------------
From: fogaudionews fogaudionews@xxxxxxxxxxx
Date: Wed, 2 Feb 2005 14:36:08 -0500
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: NAMM follow-up, some major decisions to make


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

----- Original Message ----- 
From: <gogins@xxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, February 02, 2005 10:30 AM
Subject: [gmpi] Re: NAMM follow-up, some major decisions to make


> 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


--------------------------------------------------------------------
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

Other related posts: