Hi Mathias, > (2) interfaces "forgotten" in a service description in the first place > that have been added later on. Strictly spoken this is an ugly hack as > the type is changed incompatibly and it just didn't create problems > because it is "documentation only" and no code or type information was > created for it. It would have been better to create a new service name > for the new combination of interfaces. > This hack is not possible in for MI interfaces as (different to "old > style" services) we enforce the compatibility of interfaces. So the "new > style" service concept now enforces the proper use of the "optional" > keyword - IMHO nothing that can be seen as a disadvantage (except if > lazyness is important).
This is the point which I constantly and strongly disagree with. Even if the theory says that an UNO service is and was a mere contract of functionality between two parties, the reality is that *a lot* of our services are descriptions of concrete implementations. Replacing our current implementation of an arbitrary service with another (external) implementation, which supports the same contract as documented in IDL, will most probably fail for nearly all services at application level. There are various reasons for this which I'm not sure are worth discussing here, but IMO that's the current situation. A service at application level describes what users can expect when using this service *implementation* in OOo. I don't see how this is wrong or bad, since I'd claim that services such as e.g. a css.form.FormController are that highly specific to OOo and the way OOo treats things, that every talk about re-using this service in other applications, or re-implementing it externally to OOo for usage within OOo, is merely illusionary. Of course this is different for lower-level services (wherever we draw the line here - but there is a separation between udkapi and offapi for good reasons). However, for high level services, I am pretty sure the non-availability of optional interfaces/properties would have given us an inflation of Foo2/3/4/5 services (I'm quite sure I would have reached the number 5 or higher a few times - my services usually *live* and evolve). This would have made the API more complex, more difficult to understand (for its user), more difficult to describe and implement (for its implementor) - for no good reason except some theoretic arguing. I'd even vote for relaxing the current restrictions of compatible APIs. I consider highly OOo-specific services a good thing: I consider *every* UNO API a good thing, since it allows scripting the Office, and I doubt that highly OOo-specific implementations can be reasonably and understandably described with non-OOo-specific API. Thus, I would even vote for relaxing the compatibility restrictions: Heck, please allow me to add new interfaces/properties/attributes to existing services/interfaces while they grow. Don't let us stay with a 5-year-old design just because in a very esoteric theory, somebody could have created another implementation of this service. OOo is evolving, why isn't its API allowed to evolve in a *usable* way? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
