Re: service stereotype thingies

[Maciej Stachowiak <mjs eazel com>]

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

> 
> > But if GNOME has to eat some breakage, it's unfair to say you guys
> > should not suffer any changes, even when technically appropriate. Or
> > at least I do not want to see Bonobo just become a clone of UNO.
> 
> I'm not speaking about NO changes, I just want to avoid all changes which 
> are avoidable at all.

OK, fair enough.

> > "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.
 
> > The term "service" is incredibly broad
> > and can mean anything. To me it's like calling something "arg" or
> > "param" or "thing". ServiceSpec clarifies that it's a description of a
> > service, not a CORBA server, a network server, not a service in the
> > CORBA sense like "event service" or "trader service", not a service in
> > the totally abstract sense, etc.
> 
> This IS the same as for "interface". An interface in an IDL does mean the 
> specification not a specific implementation. And so is a "service" within 
> an IDL the specification for a CORBA server. It does not seem we make any 
> progress in this discussion ;-(

OK, fill in this analogy for me, maybe that will help:

interface is to implementation as service is to _______________

> > I'm not going to fight this out with you, but I will be disappointed
> > if you think only GNOME should change interfaces, and not open-office.
> 
> No! If that's the point, absolutely not. OpenOffice will have to "change" 
> interfaces too. The point is just: We can NOT change! All what we can do 
> is, supporting the old and the new set. So I just want to reduce the 
> number of interfaces where we have to support two version.

That's fair.
 
> > FWIW I also want to change the service spec format from whatever your
> > current format is. I have considered XML, but perhaps something
> > IDL-like where you can list mandatory and optional IDL interfaces and
> > include an OAF query for attribute requirements would be nice.
> 
> 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. XML is great for 
> different software syttems, and for emergency it is human 
> readable/writeable, but not ideal for that purpose. And as you know, it's 
> hard that people write documentation at all, so don't make it hard for 
> them to write documentation.

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. Can you explain to me how a client uses a
service? What does UNO do with the service definition in the IDL.

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.

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

 - Maciej