incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Bergmann <>
Subject Re: [discuss] remove of binfilter module
Date Wed, 15 Jun 2011 08:32:35 GMT
On Wed, Jun 15, 2011 at 9:51 AM, Christian Lippka <> wrote:

> Preferred extensions are extensions who only use the UNO API. Those
> extensions
> are working with every OOo build that did not break the API compatibility.
> The next level of coupling for extension is a c++ extension that uses the
> Uno Runtime Environment (URE). This is a set of low level modules with
> defined
> interfaces that in the past stayed compatible during minor version changes.
> The highes level of couping for extension is a c++ extension that directly
> links to any OOo module above the URE level. Those extensions only work
> in the specific OOo version they are compiled for.

I would state it somewhat differently:

First, URE contains the code necessary to use UNO in any language (C++,
Java, Python, ...); it just happens that for C++ it provides substantially
more functionality than for other languages, including functionality that is
more "convenient basis layer for OOo" than "pure UNO runtime."  URE has a
(so far) compatibly evolving interface.

Second, OOo has a UNO-based interface.  It consists of a large number of
methods and data types, specific in nature to OOo, expressed in UNO.  This
interface, too, is (so far) evolving compatibly.

A "clean" extension (regardless of language) makes use of the above two
stable interfaces.  A "dirty" extension, on the other hand, directly
accesses functionality through channels other than those two stable

Binfilter is kind of the later. It is something special as it does not
> directly
> use the UNO API but the XML format to communicate with the core Office.
> Therefore it is possible and IMHO desirable to put binfilter and all
> modules binfilter use in a separate repository that builds an optional
> extension that can be used in any upcoming OOo version.
> Usually code duplication is the root of all evil. In this case it is
> justified as
> there should by definition be no more work done on the binary filters
> as the feature set of binary filters is locked. In the past there where
> only
> two types of work done in the binfilter module. The small part was of
> course
> to fix security issues found in the filter code. This will obviously have
> to
> continue. The major work caused by binfilter was to adapt it to changes
> to underlying modules. This was not only wasted work but also had
> the chance to introduce regressions.

A third part would be to reflect bugfixes in the copied-from modules to the
copied-to modules.  And that's where the costs of duplication kick in.  I
would prefer to avoid duplication.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message