incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: [discuss] remove of binfilter module
Date Wed, 15 Jun 2011 13:24:10 GMT

Valuable analysis.  Thanks Christian.  And an ideal way to look at the refactoring.  

 - Dennis

I don't know why it can't be in the same SVN repository though - there is nothing magical
about SVN trunk or trunk even being at the top (of the project's chunk of the global SVN)
except by convention.

-----Original Message-----
From: Christian Lippka [] 
Sent: Wednesday, June 15, 2011 00:52
Subject: Re: [discuss] remove of binfilter module

Am 15.06.2011 00:29, schrieb Greg Stein:
> On Tue, Jun 14, 2011 at 17:20, Christian Lippka<>  wrote:
>> ...
>> Proposal
>> I suggest to remove the binfilter module after the code has been provided
>> under the AL.
>> Therefore we have it inside the SVN and could re activate it later.
>> Preferable as a separate
>> extension.
> I'm unfamiliar with OOo's extension system. How hard would it be to
> add "import OLD format $FOO"(*) as an extension?
In a way the binary filter for old StarOffice formats are already an 
extension. The
Problem is that they are not build independent of OpenOffice like other 
Therefore they add a lot of code to the core codebase.

I do not know if apache allows to have multiple svn repositories for 
each project.
But moving binfilter to a separate repository and refactor it to become a
build independent filter makes sense. Since it does not alter any core 
stuff, it is also something that one or more developers can work on without
interfering with ongoing core development.

The following text is more directed towards developers so let me restate
my high level goal again and all non devs can skip the last part :-)
I do not want to remove the feature to load old documents forever. I just
want to ease the burden of maintaining the OOo source code and help
us get this baby flying sooner and not later. If we have resources and time
for this than it will be re added later. But such work should be prioritized
as soon as we have something usable to show.

Some background on the OOo extension system. There are multiple levels of
extensions. An extension is everything that can be optionally installed 
the extension manager. An extensions communicates with the office code
by using the UNO API available. This can be used from all languages where
we have a UNO bridge, f.e. java, python etc.

Preferred extensions are extensions who only use the UNO API. Those 
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 
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.

Binfilter is kind of the later. It is something special as it does not 
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.

> If it can be implemented "soon" or "later" as an extension, then it
> seems moving this in that direction makes sense *regardless* of the
> binfilter problems (ie. as a way to modularize). And that you could
> start out by tossing everything on Day Two, then letting the
> "interested devs" bring the feature back as a set of one or more
> extensions.
> Cheers,
> -g
> (*) assuming my understanding is that binfilter is *only* about
> importing archaic formats

View raw message