Unpublished UNO API

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

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeapi.openoffice.org
For additional commands, e-mail: dev-helpapi.openoffice.org