[gmpi] Re: COM was: low level API - Abstract Factory summary
- From: "B.J. Buchalter" <bj@xxxxxxxxxx>
- To: "gmpi@xxxxxxxxxxxxx" <gmpi@xxxxxxxxxxxxx>
- Date: Fri, 11 Feb 2005 13:18:17 -0500
on 2/11/05 11:59 AM, Mike Berry at mberry@xxxxxxxxx wrote:
> B.J. Buchalter wrote:
>>
>> But other than the toll-free bridging to C++ on windows and this enforced
>> versioning, it is not clear how the other aspects of COM are really helpful
>> in this contexts. BTW, I did read the links that have been posted here about
>> COM; this has only tended to enhance my perception.
>>
>
> I certainly expect that we can use multiple interfaces on single
> objects to our benefit. There are a number of capabilities in the reqs
> on both the host and plugin sides which are optional. Each of these
> should be isolated into an interface which does not need to be supported
> and which the caller uses a query mechanism to determine support. This
> should make it easier on developers to sort out the required parts of
> GMPI from the optional ones.
Ok. This is the part of COM that seems to be really kinda messy to me
(multiple disjoint interfaces on one object), and very likely to expose
implementation bugs due to the requirements on reference counting the
interfaces and the object (cf. the COM cookbook URL that Vincent posted in
his last post to this list).
I sort of like the concept of COM interfaces providing factories for
optional objects that provide the optional interfaces. This way, you only
have one disjoint interface per object type; interfaces can be extended by
adding a new UUID for the extended interface that adds to the existing
interface. This way, the object only needs to maintain one vtable per
object, and does not need to thunk the object pointer for each interface.
Or was I so dazed by the apparent complexity of implementing multiple
interfaces on one object that I am missing something simple?
> I also think that there are potentially some benefits to the using COM
> objects at smaller scope than the whole plugin. For instance, I'm not
> sure how we are going to work out the tempo queries from plugin to host
> (and I'm not suggesting talking about it now, simply digging for an
> example), but the host might give the plugin a COM object which can be
> used to query for tempo information. In some hosts, this might simply be
> an interface to the host itself, but in other hosts it might be a
> smaller object. The big advantage here is that the host can then attach
> its own information to the object, without having to write a new
> mechanism to support this.
This makes sense to me.
Best regards,
B.J. Buchalter
Metric Halo
5 Donovan Drive
Hopewell Junction, NY 12533 USA
tel +1 845 223-6112
fax +1 603 250-2451
----------------------------------------------------------------------
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:
