Re: service stereotype thingies

[Michael Hoennig "(mi)" <mi sun com>]

> > > "interface" has a well-established meaning which is reasonably
> > > unconfusing in this context.
> >
> > Unfortunately not. It is actually not clear if somebody means the
> > specification or a specific implementation of an interface or even a
> > concrete runtime interface. Just my experience.
>
> 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.

> 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.

> > > FWIW I also want to change the service spec format from whatever your
> > > current format is. I have considered XML, ...
> >
> > That does even make less sense to me. It's just work for the hell of 
> > the work itself. We can rename the file extension, no problem. 
> > But XML as a source file format is a pain in the ass to edit. ...

> 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.

> 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.

> 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.

> > To me, a "service" is just another kind of stereotype, like a struct or
> > an interface. You could even generate code for it, and if it's only to
> > verify conformity of implementations.
>
> 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 :-(

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".

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.

	Michael