incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivo Hinkelmann <>
Subject Re: [discuss] remove of binfilter module
Date Tue, 14 Jun 2011 22:15:32 GMT
Hi Christian,

good idea to remove it, preferred the whole module. It saves us a lot of 
build time!


On 14.06.2011 23:20, Christian Lippka wrote:
> 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.
> Reasoning
> 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.
> Caveats
> 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.
> 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.
> 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.
> Christian.

View raw message