... unsure where to start, seems I missed some mails ...
Let me briefly sort my thoughts:- We (OOo) do provide APIs (Uno, C/C++, Java, BASIC etc.) more or less for modularizing / unitizing OOo. - We do regard some of these APIs to be for internal use only, while others are available for public use. - The internal ones are (inherently) unstable, while public APIs in general should be stable (though some may still be on their way). - We do regard stability of APIs as important for 3rd parties as well as for our users, so that a user can expect a particular application (e.g. extension) to work in a particular set of OOo versions. - Obviously an API may earliest be used with the first OOo version providing it. - Historically we aimed for only adding APIs to allow any existing application (e.g. extension) to continue working with all future OOo versions. (Note: In practice we did break (accidentally or intentionally) some APIs every once a while.) - We now seem to understand that adding new APIs w/o removing/adapting old APIs creates a measurable burden on both shoulders, ours and that of 3rd parties. On ours, as we have to maintain the stuff and sometimes may not as easily change something as we wanted, on the 3rd parties, because the learning hurdle to master all of these APIs steadily increases.
Removing/adapting an API typically means breaking it! If we do want to support such changes, we certainly want to do this in a coordinated fashion, to avoid surprises. We do need some cornerstones for this, though we should also allow to apply common sense, avoiding too much of a process.
A cornerstone may be something as to allow changes/removals for major versions only etc.
... and we need to ensure that the basics are in place, such as versioning APIs etc., to be able to deal with an incompatible application (e.g. extension) in a user friendly way.
Some years ago I thought and did favorite to never ever change an API, as I wanted to be able to always use all existing applications (e.g. extensions) in any recent enough OOo version, even if the author or origin of these application had not been available anymore. After gathering some years of experience with Firefox extensions etc., I now think that we only need (and may be should) only support any lively (maintained) extension! This means also that we can expect the maintainer to adapt the code to any (reasonably) changing APIs.
Regards
Kay
Mathias Bauer wrote:
Thorsten Behrens wrote:Mathias Bauer wrote:limit impact considerations to non-ABI-dependent UNO bindings (i.e. the assumption is that c++ components break randomly anyway for every other release, so they shouldn't block API changes)This is not true; in fact on Windows C++ extensions are very stable and at least without a base line change that should be true for other platforms as well (some discipline assumed).Hi Mathias,well, Win32 is only one platform,:-) It's the platform of the overwhelming majority of our users. As far as I'm concerned, I'm making software for users, not for ends in themselves. So for me there is some sense in trying to keep extensions working as long as the pain for the developers is bearable. We decided that it's about time to take some pain from the developers, but that doesn't mean that we should give up compatibility completely.and experience tells that in general, c++ extension *do* break between releases.No, exactly that is not my experience, not with our careful handling of baselines and backwards compatibility. If am using a very sophisticated Windows C++ extension that was made for OOo 1.x and it is still running well with OOo3. C++ extensions break for the same reason as others: because of bugs of changed behavior in OOo. There is no reason to treat C++ extensions differently.But you're right, that's not necessarily caused by ABI changes in the strict meaning of the word, a case in point is the 3 layer OOo rework.Whatever happened there, it's not something that is likely to happen much often and doesn't qualify for a general problem with C++ extensions. And BTW - again no problems with it on Windows.My take on that would be: if we allow for incompatible API changes in e.g. a major release, there's no reason not to allow incomatible changes in the C++ libs also. Maybe that's what you wanted to express.No, but that's surely something I can buy into as well. What I wanted to express is that the c++ API/ABI is fragile enough IMO to not hold back with changes that *deliberately* break compatibility there. People should really be encouraged to use (or at least wrap their stuff with) Java or Python when doing extensions; that would also quite nicely solve the problem of (non-)cross-platformness. ;)The C++ API/ABI is only as fragile as we make it. And I think we should make it only as fragile as we will make the UNO API in general. That means, if an OOo release came with an API that is incompatible to a large extent, we could also change the C++ binding incompatibly - as well as any other language binding. But changing the C++ binding with every release just because "it's fragile anyway" isn't a good idea. Regards, Mathias
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
