openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mathias Bauer <>
Subject Re: binfilter (was RE: OOO340 to svn)
Date Wed, 03 Aug 2011 19:17:56 GMT
On 03.08.2011 20:25, Dennis E. Hamilton wrote:

> What I managed to glean from the LibreOffice discussion lists is that
> binfilter will be separately installable but probably not taken to
> end-of-life.  (As platforms change, it may be necessary to make new
> builds of it.)

Binfilter already is installable separately - on Windows it's an option
in the setup that you can disable (and AFAIK it is disabled by default).
What you probably mean is that they are discussing to make binfilter a
component that is compatible cross versions and so does not need to be
installed each time when a new version of the office program is installed.

As this currently fails due to some dependencies between binfilter and
"the rest of the office" that are not stable enough and might change in
every release, this ends up in the discussion you mentioned:

> There is also discussion about moving some annoying dependencies into
> the binfilter (and other converter) branches in some case, so they
> don't have to be maintained in sync with the main distro.

That's nothing new and this has happened in the past already in several
cases. I did that by myself on several occasions. But this approach is
doomed to fail in at least two cases: GraphicObjects and vcl. At least
it would require to refactor large parts of the binfilter code to be
able to remove these dependencies. There are much more better places
where time could be invested better. [Remark: IMHO the GraphicObject
problem should be solvable with moderate effort, I doubt that this is
the case for vcl.]

But maybe this is just a problem because people want to see a problem in it.

Though in theory binfilter creates some maintenance effort due to its
remaining dependencies on other code, I can't remember a lot of
necessary work on binfilter caused by these dependencies in the last
years. In the past we already went the "remove annoying dependencies"
road for binfilter: each time when a developer made huge changes in a
module that would require larger code adjustments in binfilter, the
module that was going to be changed was copied before the change and the
unmodified copy was moved into binfilter (and hopefully ;-) stripped
from all code not used in binfilter later). As I wrote, this doesn't
work for the GraphicObject and vcl, but we already used it for most of
the bigger modules with a lot of code changes, so I don't expect a lot
of room for improvement here.

It should be mentioned that this approach only optimized the work from a
maintencance cost POV, but it made things worse in other areas:
binfilter becomes bigger each time when a copied module was added,
increasing both build time and size of the installation set. And even
the optimization for maintenance cost is incomplete as the resulting
code duplication will require duplicated work in the future at least in
case security leaks are found (been there, done that ...).

> There is also a thrust to make converters more cleanly-separated and
> having the plugin APIs work successfully for them.  Again, this is
> the gist of it.  It doesn't seem too far from ideas that have been
> floated around here, though.

I'm afraid that talking about stuff like this without actually knowing
the code will at best create confusion. So all I will say about that
here is:

We don't have converters, we have filters. And some of them are cleanly
separated already, some aren't. As long as the latter aren't going to be
reimplemented anyway, there wouldn't be much sense in investing time
into improving their modularity.

Is binfilter the next "bike shed" we are targetting?


View raw message