Hi Jürgen, all,
Jürgen Schmidt wrote:
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.
Yes. And this shows a principle problem with our goals. We have three
goals for the API which do conflict:
A) Easy - We want to have an easy to understand, easy to use, easy to
maintain, clean API
B) Stable - We want to have a stable API which never changes thus
separately developed components do work forever with all versions of
OpenOffice.org
C) Flexible - We need to have a flexible API where it is possible to
introduce additional features which are requested later on.
In principle you can not have all three things together. Only two of the
goals do fit together:
A+B: You can design, implement and review an easy and stable API for a
known fixed feature set. But additional features will likely not fit
into that design. So should we stop implementing additional features?
B+C: I think what we do at the moment is focusing on stability and
flexibility. The published API is kept stable and new features are added
by additional interfaces newinterface2 newinterface3 and newinterface4.
As a result the API is not easy and will become even more complicated
over time. I am really worried if I imagine how the API will look like
in 10 years. Who would be able to implement against that API, who would
be able to just maintain it?
A+C: The best approach looking to the future I think would be to
concentrate on an easy and flexible API. There are a lot of features
that are known to be missing and there will arise additional not yet
known ones. Implementing those features by changing the API incompatible
if necessary would keep the API understandable and maintainable. Thus
it's power could evolve in 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).
Better testing and design review of API would be definitly a good thing,
but it would not solve the problem that arises from additional feature
requests.
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.
Hm, I don't think that it is likely that no user has a problem with a
GUI change. But that is a different topic maybe.
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.
Considering just the moment of API change you are right, but considering
the evolution of the API over years we might win much more customers
when the API gets cleaner and easier.
Juergen
Said that, I strongly vote for having a versioning mechanism.
So I also would strongly vote for having a versioning mechanism, also
for published API.
Just my two cents,
Ingrid
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
