Changes needed for "LibreOffice 4"
sbergman at redhat.com
Thu Jul 26 06:07:34 PDT 2012
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
> 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
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.)
More information about the LibreOffice