Frank Schönheit - Sun Microsystems Germany wrote: > 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.
I didn't express my personal opinion here - I just looked on the matter from a consistency point of view. As the idea of strict compatibility is an integral part of UNO it can't be denied that the "new UNO" fits better. But while we are at it: OK, lazyness is important. :-) Means: I also would like to see a bit more flexibility - not as a creeping process but as a "built-in" ability where API users can see where they can rely on type safety and compatibility and where they can't. > 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. It wouldn't make it more complex, IMHO having a service with a lot of optional interfaces is more complex than having several services with a clear description of its function set. "more" does not need "more complicated", often it's exactly the opposite. > 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. I fail to understand how this is related to the question whether we need "old style" services. Possible boundaries between "OOo specific" and "non-OOo-specific" are too unsharp to judge your comment. I wouldn't like to let API users guess. > 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? In case of compatibility we not only deal with implementors but also with "clients". I agree with you that most of our services and interfaces can be changed incompatibly without damaging existing implementations using them as indeed in most cases there are no such implementation outside of OOo. But how shall we deal with client code? What's our "story" about that? Before we examine the content of Pandora's box in closer detail here - can we agree to move that discussion into another thread? I would like to come back to the question: do we still need "old style" services except for backward compatibility? If I say: We don't need them. The only useful purpose they can serve is some flexibility in service design that is desirable for *some* kinds of service. Thus we should think about a more explicit way of specifying such "services". Can we agree here? Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
