Re: service stereotype thingies

[Maciej Stachowiak <mjs eazel com>]

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

>
> >
> > Really? I always use "server" or "implementation" to refer to an
> > implementation of an interface, and "client" or "proxy" to refer to
> > the client-side stubs.
> 
> But you say "query_interface" - or not? But you do not get an IDL file! 
> You get something which implements what the specification from the 
> interfaces's IDL file specifies. That's what I meant.

You query for something that provides an interface I guess. Typically
what you get is called an "interface pointer" in COM, or a "client
object" in Bonobo, not an "interface".
 
> > OK, fill in this analogy for me, maybe that will help:
> >
> > interface is to implementation as service is to _______________
> 
> interface is to implementation as service is to implementation - both are 
> part of the specification, of cause.

See, that is the part I have a problem with. As a well trained CS
monkey I think of interface and implementation as parallel and
converse concepts. Service and implementation do not work that way as
a pair for me.

(In case it was confusing, I meant the analogy to be on the abstract
level, not the literal level of the UNO component model on which you
seem to have taken it).

> 
> > Well, we already have this problem with .oafinfo files. I am thinking
> > of how to integrate things nicely with the whole system. Maybe
> > pseudo-IDL makes sense. 
> 
> Pseudo-IDL sounds good! It actually addresses a funny point: When I speak 
> German, I can always simply use the German word "Schnittstelle" if I mean 
> "interfaces" in general (consisting of structs, interfaces, services and 
> probably even Java or C++ classes and C function declarations). And if I 
> really mean an interface (which has a specification in IDL), then I can 
> use the English term :-) Why I mention that? Because the "I" in "IDL" 
> means "interface" in the sense of "Schnittstelle" - because there are not 
> just interfaces in.

I am afraid my German is too weak to quite get this. Ich habe Deutsch
für nur drei Jahre studiert.

> > Can you explain to me how a client uses a
> > service? What does UNO do with the service definition in the IDL.
> 
> Currently UNO does nothing with the service specification from the IDL. 
> We just generate HTML documentation from it.
> 
> A client can do that (in a simplified C++-like notation)
> 
> XSomething xSomething = 
> 	aGlobalServiceManager.createInstance( "com::sun::star::some::Thing" );
> 
> or that:
> 
> XServiceInfo xInfo( 
> 	xSomething->queryInterface( "com::sun::star::lang::XServiceInfo" );
> if ( xInfo->supportsService( "com::sun::star::some::OtherThing" ) )
> 	...
> 
> Of cause, the second usage is rare (if it even exists in OpenOffice). 
> It's more, that both developers, the one of the component and the one of 
> the client, know what they have to do. 
> 
> What would be a good thing, is to generate some test code which checks 
> whether an implementation which states to support a certain service, 
> really does it - at least has the right interfaces and properties.

Hmm, it looks like the service thing serves a mostly documentation
purpose, and the actual relevant API calls that are related are not
going to be burdensome to change, if need be.

I can imagine the first one would be, in OAF/Bonobo-speak:

StarOfficeSomething something = 
        bonobo_object_activate ("services.has('StarOfficeSomething')");

The second will need some sort of introspection interface.


> > OAF already has a powerful way to describe a set of constraints an
> > object, namely an OAF query, so it only makes sense to me to leverage
> > this somehow. It would be lame if service specs were totally separete
> > from oaf queries and we had two ways to specify the same kind of info.
> 
> Right, these both things should not be totally separate. But services are 
> more than just an OAF query - mostly becasue there are more words to it. 
> Yet, I could imagine generating (named) OAF queries from service 
> specifications, for example.

Yep, that's exactly what I can imageine, but also oafinfo files would
specify the services a given server implements.

> >
> > To me using the term "stereotype" to refer to a struct or interface is
> > super confusing in itself. I guess we just have different sets of
> > technical language we are used to. I think mine is representative of
> > most US-resident hackers at least.
> 
> I am not so sure about that. My terminology here is taken from UML and 
> not made up by myself. Though I have to confess, UNOs terminology is not 
> completely from UML. Our idea of aggregation is different - and 
> nonexistent in UML :-(

That may be. I've never heard the term "sterotype" used this way, but
I don't know anything about UML.

> And to clarify: A struct or A interface are NOT stereotypes. Interface 
> and struct itself are both stereotypes. You probably call them "meta 
> type"? "type", btw, one of your suggestions for substituting "service" is 
> "an instance of any stereotype" - thus it could be a certain interface or 
> struct" - as well as a certain "service".

Er, yes, I guess meta-type would be what I would call it. Only not,
because I would use that to refer to a parameterized type. "struct"
and "interface" are parameterized types only in the most incredibly
general sense.

I think I was totally misunderstanding what "stereotype" meant until
just now. Thanks for the explanation! :-)

> 
> BTW: Merriam Websters dictionary says: "stereotype (noun): something 
> conforming to a fixed or general pattern; especially : a standardized 
> mental picture that is held in common by members of a group and that 
> represents an oversimplified opinion, prejudiced attitude, or uncritical 
> judgment." - Fit's both, if at all.
> 

Yes, I am not talking about dictionary definition, just terms I
know. I can see how "stereotype" would be totally inappropriate to
refer to a service specification.

 - Maciej