Re: OAF and XServiceInfo

[Maciej Stachowiak <mjs eazel com>]

Michael Hoennig "(mi)" <mi sun com> writes:

> > > Core reflection, btw, is analyzing the interfaces of objects down to
> > > methods and their argument types and return types. Introspection
> > > interprets that stuff and gathers additional data from method calls (i.e.
> > > to find out runtime properties), it is mostly for scripting engines.
> 
> > This is already handled in CORBA by DynAny, DSI, DII, the Interface
> > Repository and the like. Do you think the OpenOffice-specific
> > technologies for this are better than the CORBA standard ones? I am
> > not very familiar with either.
> 
> If you don't know either of them, why do you discuss about it? It was 
> actually you, who started talking about (a third) spec for reflection.

No, I think you misunderstand what I meant by introspection. I just
meant being able to get the object's OAF attributes (which are quite
similar to the information provided by XServiceInfo), not reflection
in the IR/java.lang.reflect sense. This is why long discussions by
email suck, I think we may have talked past each other.

> BTW: Our reflections and introspection design comes from Java APIs. And 
> that we can hardly do thinks really different from Java, I already explained.

The CORBA specs that handle reflection/etc do so in a cross-language
way. I know Java has a CORBA mapping. Does that not satisfy the
requirements?

> 
> Ok, so you are speaking about a query over ALL runtime objects. That was 
> not clear to me. I was just speaking about inspecting a specific runtime 
> object. Your feature sounds nice, but still, I would prefer having two 
> different components  -just sharing the query code.

But that would mean two running daemons which are close to
identical. Maybe that is more useful. I am not clear on why. I know
Miguel has asked me to put support for stuff totally unrelated to
activation in OAF before, like queueing support and I am happy to add
such things in the interests of fewer running servers.

> > But to be honest, I don't know what you do and don't want to put in. 
> > I want to see something which provides information similar to
> > XServiceInfo and also to OAF_ServerInfo for running objects. Are you
> > talking about that, or the low-level introspection stuff above?
> 
> Yes, I think we had to different definitions of "introspection" here. But 
> I already defined, which is what in my terminology.
> 
> But, anyway, I don't want to talk about runtime object queries right now. 
> I think there are more important problems.

Well, um, you brought it up.

> > > > If service specs were entirely separate from OAF, all the info in the
> > > > service spec would have to be duplicated in the oafinfo file.
> > >
> > > I would mostly say, C code is duplicated in o files as well - somehow ;-)
> >
> > But the .o files are generated from the .c files by a compiler. If you
> > think .oafinfo files can be automatically generated from .svc files or
> > vice versa, that would be great but I cannot think of how at the
> > moment.
> 
> That was my idea. I think it is possible to generate .oafinfo files from 
> service specs. The other way around is not possible, because service 
> specs contain a lot of words called "documentation" as well ;-)

1) oafinfo files can contain comments

2) oafinfo files contain info which is not in service specs; at the
   very least activation info for a particular implementation.

Perhaps it would be wise for me to read some service specs and for you
to read some oafinfo files.

 - Maciej