Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
Second, we neither have nor plan to have in place a mechanism to detect
that some UNO component/OOo extension uses an old revision of some
unpublished API. That is, there will not be any warning if you deploy
such a component/extension into an environment where it will not work,
and at runtime using that component/extension can have unexpected effects.
Perhaps we should have such a mechanism then.
that would mean that we go back or better improve and extend our
component xml descriptions. This description already contain information
about the implemented services and additional used types. This
information + some kind of versioning would enable the possibility of an
early check.
But it means also that components may not work with future versions
and we have to rethink our compatibility paradigm.
Going away from the "every released API must be stable" paradigmn by
introducing the "published" keyword/feature was a great relief, and
prevented some immature interfaces already (we have enough of them in
the API created before).
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.
I would agree that we still have some missing functionality here.
But with ~700 unpublished API's you can get the impression that we use
unpublished API's to be flexible for the future. API's intended to be
used public should be published asap. It show me more that we have to be
more careful with API's, i think we have to include API's in the spec
process and we really need complete tests, examples and documentation
before the API's get released. Writing tests, examples and documentation
often shows potential specification errors and at this time we have the
chance to change it.
The biggest problem with a lot of API's is that we have developed and
implemented them but neither we have used it internally nor somebody
have used them externally over round about 2 years and we have made the
mistake to keep this initial API compatible (for probably only a few
external customers).
Furthermore i would say that the API's are more important than the UI.
But don't misunderstand me the UI has to be clear, intuitive and easy
... But when we find a problem in the UI we can easy change or correct
it with the next release and probably no user has a problem with this
change. But changing API's we can break potential extensions o customer
applications using the API and that is more critical from my point of view.
Juergen
Said that, I strongly vote for having a versioning mechanism.
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
