incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphael Bircher <>
Subject Re: [discuss] remove of binfilter module
Date Tue, 14 Jun 2011 22:45:01 GMT
Am 15.06.11 00:15, schrieb Ivo Hinkelmann:
> Hi Christian,
> good idea to remove it, preferred the whole module. It saves us a lot 
> of build time!
Build time no matters in this case. No user will understand this 
argument. And the question is for wath we are here. To make a good 
product for end user, or to play around with code?

As QA I can't accept to remove samething to save Build Time, sorry. 
Byside you can dissable binfilters if you build samething who does not 
afffect the binfilter.

Greetings Raphael
> Cheers,
> Ivo
> 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.

My private Homepage:

View raw message