Unpublished UNO API

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: 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
> 

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