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 -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[email protected]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
