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 Tue, 14 Jun 2011 23:08:04 GMT
It strikes me that it is better to refactor and have the binfilters be independently pluggable
without the code dependency issue you mention.  That seemed better when I saw it discussed
for LibreOffice as well.

My concern is from my background in document management systems.  There may be conditions
that prevent conversion of the files.  In those cases, it is necessary to maintain some way
to continue access to the documents using newer clients, at least until the bits of the documents
can't be preserved any longer.  Whether these could be separate plug-ins outside of the main
distro(s) is a different question.

 - Dennis

-----Original Message-----
From: Christian Lippka [] 
Sent: Tuesday, June 14, 2011 14:20
Subject: [discuss] remove of binfilter module

Hi all devs,

I know we all wait for the code and the missing contributions from 
Oracle. But no reason to plan ahead.
One think I like to see is the removal of the binfilter module after the 
code has been contributed.


The binfilter module is a huge set of code duplicated from all 
application modules and various high level
modules. It's main purpose is to implement load and store of pre xml 
binary document formats
from the StarOffice era. Removing this code would spare us a lot of work 
while we try to have our
first release buildable and running.


While replaced by xml formats way back in 2002, there are still 
documents in the binary format
around so at least loading them may be a requirement for some users. 
There is a consensus
that only the import part is needed, but removing just the export part 
is tedious work so no
one has done it yet.


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

Technical Background

The binfilter module was created by copying all application code that 
was involved in loading
and storing the binary document format. That code was then striped down 
to only handle
the persistence part including the streaming operations. During import, 
the complete document
was streamed into memory using the old implementation. Then the 
binfilter copy of the xml filter
transformed the in memory model into a temporary xml 
stream. This stream was
then imported by the current document implementation.
The reason for the invention of binfilter  was the high coupling of the 
binary format and
the model implementation. Changing the actual implementation started to 
get harder as the
binary document format was nearly a 1:1 memory dump of the model. So 
putting all the
binary stream operators aside enabled us to make drastic changes to the 
model implementation.

While the binfilter only communicates with the office code using xml, it 
still is highly dependent
as it uses some low level modules. Therefore each time those modules 
change, the binfilter
module must be rebuild. Some developers, including me, proposed to have 
all needed modules
cloned into the binfilter module. To have a completly independent 
extension that does not need
to be build when the office itself is build.


View raw message