Hi Stephan, >>Now what you're saying is that efectively, we're in the same situation, >>again: Don't change any released API, as existing extensions might rely >>on it, and will disbehave (and probably crash, if they're C++) if used >>in conjunction with the new API. This makes, IMO, the "published" >>concept absurd. > > No, I did not say that unpublished API cannot be changed in general.
Yes, I overstated this somewhat ;) > I also got a Sun-internal mail that requested a detection mechanism for > usage of broken unpublished API, and a versioning mechanism for > published API. Let me explain to you why I think that what we have now > is all we can reasonably get: Somehow I was afraid :) you would be going to say exactly this: It's not possible. (snipped some large convincing parts) > However, if you are willing to list unpublished API (at a level that > seems appropriate, like either a whole API or only individual types) in > extensions using it, you can leverage the extension dependency feature > introduced in OOo 2.0.4 (see > <http://specs.openoffice.org/appwide/packagemanager/extensiondependencies1.odt>): > > For each version of an unpublished API, invent a dependency token. In > an extension that uses unpublished API, record the corresponding > dependencies. In OOo, specify those (and only those) dependencies as > fulfilled that correspond to the current versions of any unpublished API. Interesting approach, but probably equally painful (and error-prone) to maintain as manual type dependencies, on both the OOo and extension side. > Anyway, I assume the latter case is what people think about when they > request API versioning: Be allowed to change an UNO interface type, > with the consequence that old extensions might no longer work, and have > the system safely detect that some extension will actually no longer > work. This "saefly detect" is the interesting point, yes. Admittedly, I am not aware of any extension-enabled application which is able to do this (even the Mozilla extension framework, which I consider pretty powerful, cannot do here, as own sad experiences showed :-\ ). > (Promoting this model does have the drawback that it will lead to > extensions that work with some version of OOo but not with later ones, > something that should not have been possible until now, at least not > theoretically in a clean world. After all, you probably can't have your > lunch and eat it too.) I believe we will never be able to completly prevent this: I suppose nobody really wants to restrict (technically or by policy) extensions to published API, as this would take away much of the power of extensions. Producing mature API from the beginning is a nice idea - which we should definately strive to fulfill! -, but will never be completely possible. Even then, experience shows that defining API without implicit assumptions, i.e. API which is really specified to a full extent, is not an easy thing, either. But extensions relying on an underspecified contract are prone to break with changes in the interface's implementation, too ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
