Hi Ingrid,
Ingrid Halama wrote:
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
here are three different goals in one ;-)
i would combine easy to use and clean API and would disagree in the
point "easy to maintain". If a more difficult maintenance process would
allow us more flexibility i would vote for it because we would have it
under control and probably know what we are doing.
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.
i agree and i am personally are flexible but we have to think carefully
about this change of our API paradigma and should ask our customers if
they can live with solutions that work only with version XY or older and
potentially not with future versions.
I am always happy when one of my demo components developed for
StarOffice 6.0 (before OO.org) work with StarOffice 8 as well. I think
it can be a good reason for customers to switch to SO/OO.org using our
API (with java for example) because they know that the implementation of
macros, some integration and/or extension is a one time investment and
would work with future versions as well. It is not really calculable for
professional ISV's or bigger companies if they have to check their code
with every new version of the product.
MS has shown how successful they were with their compatible API's over
years.
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.
i would love to have a working versioning for UNO types but i think
Stephan has already described why it is not possible.
I can only promise that we will think again about it and any kind of
ideas are welcome.
Juergen
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
