Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dennis.hamilton@acm.org
 designates 75.98.160.130 as permitted sender)
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <ooo-dev@incubator.apache.org>
References: <4DF7D090.5090000@lippka.com>
In-Reply-To: <4DF7D090.5090000@lippka.com>
Subject: RE: [discuss] remove of binfilter module
Date: Tue, 14 Jun 2011 16:08:04 -0700
Organization: NuovoDoc
Message-ID: <019701cc2ae7$eb4a5170$c1def450$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQH87hovnVUCBX/cGD18nlZa0vkE7ZRb7O4g
Content-Language: en-us

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 [mailto:cl@lippka.com]=20
Sent: Tuesday, June 14, 2011 14:20
To: ooo-dev@incubator.apache.org
Subject: [discuss] remove of binfilter module

Hi all devs,

I know we all wait for the code and the missing contributions from=20
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=20
application modules and various high level
modules. It's main purpose is to implement load and store of pre xml=20
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=20
documents in the binary format
around so at least loading them may be a requirement for some users.=20
There is a consensus
that only the import part is needed, but removing just the export part=20
is tedious work so no
one has done it yet.

Proposal

I suggest to remove the binfilter module after the code has been=20
provided under the AL.
Therefore we have it inside the SVN and could re activate it later.=20
Preferable as a separate
extension.

Technical Background

The binfilter module was created by copying all application code that=20
was involved in loading
and storing the binary document format. That code was then striped down=20
to only handle
the persistence part including the streaming operations. During import,=20
the complete document
was streamed into memory using the old implementation. Then the=20
binfilter copy of the xml filter
transformed the in memory model into a temporary OpenOffice.org xml=20
stream. This stream was
then imported by the current document implementation.
The reason for the invention of binfilter  was the high coupling of the=20
binary format and
the model implementation. Changing the actual implementation started to=20
get harder as the
binary document format was nearly a 1:1 memory dump of the model. So=20
putting all the
binary stream operators aside enabled us to make drastic changes to the=20
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=20
change, the binfilter
module must be rebuild. Some developers, including me, proposed to have=20
all needed modules
cloned into the binfilter module. To have a completly independent=20
extension that does not need
to be build when the office itself is build.


Christian.