Re: Interface introspection
- From: Alex Graveley <alex helixcode com>
- To: Michael Meeks <michael helixcode com>
- Cc: Joe Shaw <joe helixcode com>, Miguel de Icaza <miguel helixcode com>, gnome-components-list gnome org
- Subject: Re: Interface introspection
- Date: 20 Nov 2000 22:49:50 +0500
Hi,
> 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 ).
Hehe. I talked with Maciej a bit yesterday and proposed an idea very close to this (I seem to have missed the original XServiceInfo discussion).
> 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.
Another thought I have been tossing around is to have an optional OafActivatedObject interface, that could be QI'd for by oaf before returning the object from a query. Oaf would then call a set method, passing in the object's ServerInfo struct and setting a reference to the ActivationContext or ObjectDirectory from which the object was activated.
This would allow for client's to get at a server's oafinfo properties as was Joe's original request. It would also allow for the use of a remote oaf, to do federations with other oafd's and bootstrapping of ObjectDirectorys for the local oaf. It could also allow changes to a ServerInfo's properties to be persisted back to the original oafinfo on whichever machine activated the object.
This does cross a line in that oaf would be manipulating the objects it activates without prompting from the client.
Thoughts?
-Alex
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]