Re: Interface introspection

[Maciej Stachowiak <mjs eazel com>]

Alex Graveley <alex helixcode com> writes:

> 
> Forgive me, but perhaps you should take your own advice. If you had, you
> would know that components in COM are not allowed to dynamically change
> their interfaces. QI for COM was designed to be static and reliable for
> the same component.

I think you may have misunderstood. Once QI has returned a particular
value for a particular interface, it cannot change. But the first time
anyone QIs for an interface, the component may create that interface,
dynamically decide whether to create it, or do any of a number of
other things, and advanced COM programmers use tricks like this a
lot. When binary reuse is used, whereby another existing component is
added as an interface to the running component in response to a QI,
it's not necessrily even possible to know the full set of interfaces
that other component will support.

So in summary, the COM rule is that components are not allowed to
dynamically change the interfaces _that they exposed_. The last part
is important.

I know very well that QI is symetric, reflexive and transitive, but
that is really not the point; the point is that requiring a component
to be able to list all the interfaces it supports adds a contraint
that COM intentionally avoided adding.

> Since bonobo makes no promises as to QI's dynamism, associating
> currently supported interfaces with the component and not the activation
> mechanism is the way to go, and such an addition to Uknown is arguably
> necessary. At the very least making ComponentProperties a mandatory
> interface.

Plase read the two chapters I suggested if you want to discuss this.

There are very good reasons why IUnknown has only the three operations
it does, and the book explains them way better than me.

A ComponentProperties interface could be a good addition, but we
shouldn't add it to Unknown, and we should not make it mandatory
because that overconstrains the component model. It would make a
Bonobo<-->COM bridge pretty difficult for one thing.

I suggest we not stray from the IUnknown model. But even if the
tradeoff is worthwhile, we should make an informed decision.

(As for OAF - reusing the existing component metadata/introspection
code there and making it not tied to activation is, I think, a good
strategy for making it easy to make this information avaiable for any
object; another possible strategy is to instead duplicate the
functionality in an orthogonal way, but as I said ont he "services"
thread a while back, I don't think that's the best way to proceed).

Regards,

Maciej