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: dev-unsubscribe api.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org
|