Re: Changes needed for "LibreOffice 4"

On 07/20/2012 05:20 PM, Lubos Lunak wrote:
>   Option c) can mean either stopping supporting some file formats, or breaking
> API/ABI compatibility. For file formats we want to do this with binfilter
> AFAIK, nothing else, and this is a lot like b) as well in that it's just done
> and that's it. Breaking API/ABI compatibility for LibreOffice means breaking
> (only) extensions, which depending on the changes may need recompiling,
> adjusting or complete overhaul.

Breaking API compatibility is not only about breaking extensions.  It 
also affects scripting (aka macros, that "Tools - Macros" stuff, which 
can also be embedded in documents) and external code interfacing with LO 
(like unoconv).

>   And after all this is done, it should be easier to actually talk about LO4,
> because we'll know what the talk is actually about. As for the technical
> details (i.e. c) ), we'll need to decide how to handle the breakages it'll
> cause for extensions. Note that as extensions use only URE (right?), affected
> code is actually relatively small (AFAIK sal/, salhelper/, cppu/,
> cppuhelper/, udkapi/ and offapi/, not sure about the last one). I see roughly
> several ways:

Yes, all the above (incl. offapi), plus more: Java, Python, CLI language 
bindings; URP; officecfg/registry/schema; ...

> 4) We do 2), but we smooth it out with a transition period (backwards
> compatibility wrappers). I believe that a number of the LO4 changes can be
> done in a compatible way with just a little more work (I have quite some
> experience there from the KDE times too). For example, the
> com::sun::star::* -> uno:: change is probably doable in 3.x by introducing
> the new names that would map to old ones. This would allow us to test this
> already in LO core without affecting extensions. Another example, if we
> change rtl::OUString, we may rename and change it for LO4 and keep the old
> one for backwards compatibility. In short, this is 3) where we put more work
> into not breaking extensions.
> + extensions will need to be updated once, or possibly even not at all
> - may need some extra work (although it's a question of how much)
> - possibly some code duplication (although the old code may be later removed,
> so this may be just having a time overlap with the new/old code)
> - if LO4 needs to be out soon for whatever reason, we may not have the time

Having old and new coexist side by side has a lot of merit, indeed. 
This also includes bridging, where UNO could detect that two components 
are incompatible with each other and place a (manually or automatically 
implemented) bridge in between that can map between the two worlds. 
However, this is not without drawbacks:
- Even if some mechanism was initially only intended as a temporary, 
removing it again can easily be delayed for quite a while (cf. 
binfilter), leading to increased overall complexity for practically 
unlimited amounts of time.
- Bridge code can be poorly tested, making it useless in practice. 
(Like for an old extension that uses some obscure feature, for which 
bridging has never been tested by the developers.  The old extension 
would be discovered to be dysfunctional in new LO by users, just as if 
there had been no special bridge code available, but at the increased 
cost overall of having to write the bridge code in the first place.)

A few thoughts on "the com::sun::star::* -> uno:: change":  The 
com-sun-star prefix is used in at least two places:

1  As a namespace for UNOIDL definitions in udkapi/offapi (which leads 
to like-named namespaces, packages, etc. in the various language 
bindings; and to usage of string literals for service/singleton access, 
at least for old-style ones).

2  As a namespace (C++), package (Java), etc. for language-binding 
specific entities (like C++ com::sun::star::uno::Reference and Java 
com.sun.star.uno.UnoRuntime).

Whether renaming can be done compatibly is highly variable:  For 
example, many C++ entities could be renamed with typedefs, while some 
could not (templates, at least with C++98 with which we are stuck for 
now).  What could work better for C++ is a namespace alias (but maybe 
not "namespace uno = com::sun::star" as it could cause confusion in 
existing code that also uses "namespace com::sun::star::uno;").  On the 
other hand, no such tricks are available in Java.

My personal take is that such a rename causes way too much deliberate 
breakage to be worth it.  (After all, a name is just a name.  Lots of 
projects are stuck with outdated naming, like the NextStep "ns" prefix 
in Mac OS X.)

Stephan