Re: OAF and XServiceInfo

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael helixcode com> writes:

> Hi,
> 
> 	After trying to trawl through the massive amount of verbiage on
> this subject in reverse order and still retain some clue of what is being
> discussed I think I failed. Anyhow, somewhere, someone said they wanted to
> implement arbitary object characterization ( a-la the XServiceInfo
> interface ) into OAF.

I don't know what XServiceInfo does, but perhaps it's similar to the
introspection about activated objects that I'd like to see in OAF in
the future.

> 	This seems to me an appallingly bad idea for the following
> reasons:
> 
> 	a) Oafd is a remote process always, the object handle you have
> will often be local so to characterize an object's contract you always get
> a big performance hit.

* The object reference will be local (i.e. in-process). The object
  implementations will often be remote, and almost always are.

* Introspection about attributes is not a frequent or
  performance-critical task. Indeed, Michael himself told me
  XServiceInfo is very rarely used in OpenOffice itself and the
  primary use of services is as documentation, and to activate by
  (*ding ding ding*).

* I'm not sure if it needs to be in oafd just because it integrates
  with the oaf mechanism of ServerInfo specified as XML files. That is
  all I have really proposed so far, that rather have separate sources
  of activation info and introspection info, they should come from one
  source and expose the same set of attributes.

* But boy, it would be nice to be able to do queries about running
  activated objects even if they were not activated by a standard OAF
  method. That seems rather compelling to me. It makes for a powerful
  system-wide introspection facility, not merely a per-object one.


> 	b) OAF deals with _Activation_ it characterizes pre-activated
> objects, this is the whole point in it; so you don't have to activate
> every available object to find the one you want.
> 

OAF also deals with introspection, both on unactivated server
implementations and on active running servers (what do you think
`oaf_query' is for?). It was not designed to be the be-all end-all
introspection solution, true. But I think it could naturally be
extended in this direction.

> 	It might have some redeeming features since:
> 
> 	a) Currently people have to manualy duplicate the interfaces that
> they export in the oafinfo files ( it would perhaps be nice to be able to
> fix this; this could perhaps be done with a good service implementation ).

If service specs were entirely separate from OAF, all the info in the
service spec would have to be duplicated in the oafinfo file. Your
parenthetical remark seems to be handwaving. If services were, say,
entirely implemented in Bonobo, OAF could not depend on that Bonobo
implementation as this would be a circular dependency. Creating yet a
third module solely for the service stuff seems excessive to me.

> 	b) We want to activate things based on the services they provide
> ( but this is not a real problem currently; see point a). Service based
> activation would cut down the complexity of OAF queries which would be
> welcome.

I agree with the last sentence. I can see how it could cut down a lot
of the complex queries in Nautilus down to size. But I do not
understand your parenthetical remark here.

> 	So; in conclusion it makes no sense to me to put dynamic arbitary
> object characterization out of process in an object activation
> daemon. 

I respectfully disagree. I think there are ways in which it makes
sense. However, I think this is not the only way to fruitfully
leverage OAF as a technology here rather than creating something
entirely orthogonal.

 - Maciej