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:01:48 GMT
Hi at all

I'm not sure if the Users are so happy with it. LibO had the same 
discussion same month ago, with the result uf user protests. Switch back 
to a older OOo Version is not realy a option, because it's not easy to 
install two different on one mashine.

If we will do so, we have to provide a extension as minimum. else I vote -1

Greetings Raphael

Am 14.06.11 23:50, schrieb Mathias Bauer:
> Moin Christian,
> in case we had the code in the repository, I would be glad to remove 
> it. :-)
> Means: +1.
> Regards,
> Mathias
> 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