[gmpi] Re: low level API

  • From: Mike Berry <mberry@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 02 Feb 2005 08:33:22 -0700

Angus F. Hewlett wrote:

jeffmcc@xxxxxxxxxx wrote:

The advantage of a dispatcher is you can extend the API by
adding new opcodes, you don't change the binary interface,
makes backward/forward compatibilty very easy.


That's very true. However, it depends on the richness, modularity and object-ness of the API.

For instance, if a GMPI Event is expected in some ways to behave like an object (with get/set methods mediated via the dispatcher), when you extend the functionality you can end up with a highly disordered/unsorted list of dispatcher opcodes.. either that or you have to reserve plenty of space in the opcode enumeration so as to keep like with like - so that all messages beginning with 0x1000 relate to initialisation, 0x2000 to pins and connection, 0x3000 to events...


This is where I think that an interface-based approach, even if implemented with dispatcher/selectors can be useful.


So the main entry is used to acquire various "interfaces." The interfaces could be structs with function pointers in them, or they could be subdispatchers. Generalized, this can produce a useful heirarchy, where later changes only affect the readability of subsections.


-- Mike Berry Adobe Systems

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