Re: Interface introspection

[Michael Meeks <michael helixcode com>]

Hi Joe,

On Sun, 19 Nov 2000, Joe Shaw wrote:
> So, I was chatting a bit with Miguel about whether bonobo has the
> ability to ask components for the interfaces they support. This is
> particularly useful for querying remote components, since you can't
> just access the oafinfo file. Miguel suggested that we create a
> standard interface like "ComponentProperties" to Bonobo_Unknown so
> that it could be queried and return this kind of information.

        I assume you mean 'ComponentProperties' to _The_ Bonobo_Unknown,
ie. as part of the aggregate.
  
        There is precicely 0 point in adding it to Bonobo_Unknown, because
a single Bonobo_Unknown does _not_ describe a component, a component is   
described ( on a trivial level ) by the sum of the interfaces it
implements across the aggregate.
  
        Hence, having an interface ( perhaps called ComponentProperties
) only makes a lot of sense as part of the Aggregate.
  
        NB. the ComponentProperties interface is the equivalent of the
XServiceInfo interface we discussed some time back ( to much public
misunderstanding ).

        I think Maciej's comment is a great one, being able to get an
OAFID from an activated component is a useful property ( especialy for   
easy serialization and re-activation; except damn it we don't want to do  
that do we I forgot [1]) see samples/compound-doc/sample-container's hack 
around this problem.

        Furthermore I think we should consider using 'ServiceInfo' as the
interface name, to give less pain to the Sun guys, and implementing the
following methods:

interface ServiceInfo {
  
/* New Bonobo bits */
        string     getOAFIID                ();

/* Original Sun bits */
[1]     string     getImplementationName    ();
[2]     gboolean   supportsService          (in string service_name);
[3]     StringList getSupportedServiceNames ();
};

        The Sun bits are very useful for debugging and contract
validation, and although we cannot cope with the service concept yet I
think we should stub the methods in for now.

        [1] - could return the filename of the impl.
        [2-3] - just stubs for now.

        Does that make sense ?

        Regards,

                Michael.

[1] - in fact I think this is a reasonable thing to do; re-activating the
component that wrote the data seems to be the most logical thing we can
do. The alternative is to construct a massive query, that will garentee us
uniqueness on the component we re-activate to read the data: a total waste
of time.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot