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>
Cc: "'Armin Le Grand'" <Armin.Le.Grand@me.com>
References: <00e801cc51f4$f956b0e0$ec0412a0$@acm.org>
 <BC4364E5-3A12-4D82-9B92-246507F9B34E@openoffice.org>
 <4E39844D.2090304@gmx.com> <012701cc520a$c7359570$55a0c050$@acm.org>
 <4E399EE4.5010700@gmx.net> <j1gkct$vg1$1@dough.gmane.org>
In-Reply-To: <j1gkct$vg1$1@dough.gmane.org>
Subject: RE: binfilter (was RE: OOO340 to svn)
Date: Fri, 5 Aug 2011 09:47:10 -0700
Organization: NuovoDoc
Message-ID: <00f001cc538f$5289c0d0$f79d4270$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-index: 
 AQE0/s8FI0iyA6of2KgnbOwtvAYhCwLszLdjAcpu3S4CNDi+DgKQWM5tAxlE8hSV2HV7IA==
Content-language: en-us

The only problem with [2] is that it assumes conversion is =
possible/permissible.  That is not always the case.  Now, I do not know =
there is anyone who has that problem and is (or will soon be) unable to =
run older software that accesses those formats, but we do need to be =
careful in considering this.

In the future, this problem will become more likely because conversion =
is prevented by technical means, not just an usage case (e.g., when a =
document is digitally-signed and the signature must be preserved). =20


 - Dennis

-----Original Message-----
From: Armin Le Grand [mailto:Armin.Le.Grand@me.com]=20
Sent: Friday, August 05, 2011 04:34
To: ooo-dev@incubator.apache.org
Subject: Re: binfilter (was RE: OOO340 to svn)

	Hi *,

Binfilter can pretty simply be linked statically against the remaining=20
dependencies (tools and below) and just stay there as a binary module.=20
It already is a UNO API based module, so having binfilter or not is just =

a matter of copying the binaries or not during installation, plus maybe=20
some finetuning.

My initial suggestion was anyways to not add it as a module, but keep it =

static on the version it was added in the past; being indirectly changed =

by changing the below modules for other purposes is theoretically even=20
dangerous and may introduce errors.

Seen from today I see no reason at all to keep it; there are about 20=20
versions of OOo/other derivates out there which support it and thus=20
support converting documents. Everyone who still has old docs (few after =

7-8 years I guess) is able to get a version before removal, install it=20
and convert those docs.

As discussed above, there are two possibilities (well, three, if we keep =

it as it is):

[1] Do the not too difficult step of making binfilter independent from=20
the rest by statically linking, keep it on the current version. Use the=20
resulting binary module for future versions.

[2] Completely remove it and refer any complaints from people which were =

not able to move to the new file formtats in the last 7-8 years to the=20
countless versions which are capable to do the conversion

Thus I clearly suggest to do [2] now, enough ressources (memory,=20
bandwidth, built time, ...) spent on it. Let's use the chance to cut=20
some old burdens.

BTW: Fo the interested I already mentioned some facts about it's history =

here [news://news.gmane.org:119/iufajg$339$1@dough.gmane.org]

Am 03.08.2011 21:17, schrieb Mathias Bauer:
> On 03.08.2011 20:25, Dennis E. Hamilton wrote:
>
>> What I managed to glean from the LibreOffice discussion lists is that
>> binfilter will be separately installable but probably not taken to
>> end-of-life.  (As platforms change, it may be necessary to make new
>> builds of it.)
>
> Binfilter already is installable separately - on Windows it's an =
option
> in the setup that you can disable (and AFAIK it is disabled by =
default).
> What you probably mean is that they are discussing to make binfilter a
> component that is compatible cross versions and so does not need to be
> installed each time when a new version of the office program is =
installed.
>
> As this currently fails due to some dependencies between binfilter and
> "the rest of the office" that are not stable enough and might change =
in
> every release, this ends up in the discussion you mentioned:
>
>> There is also discussion about moving some annoying dependencies into
>> the binfilter (and other converter) branches in some case, so they
>> don't have to be maintained in sync with the main distro.
>
> That's nothing new and this has happened in the past already in =
several
> cases. I did that by myself on several occasions. But this approach is
> doomed to fail in at least two cases: GraphicObjects and vcl. At least
> it would require to refactor large parts of the binfilter code to be
> able to remove these dependencies. There are much more better places
> where time could be invested better. [Remark: IMHO the GraphicObject
> problem should be solvable with moderate effort, I doubt that this is
> the case for vcl.]
>
> But maybe this is just a problem because people want to see a problem =
in it.
>
> Though in theory binfilter creates some maintenance effort due to its
> remaining dependencies on other code, I can't remember a lot of
> necessary work on binfilter caused by these dependencies in the last
> years. In the past we already went the "remove annoying dependencies"
> road for binfilter: each time when a developer made huge changes in a
> module that would require larger code adjustments in binfilter, the
> module that was going to be changed was copied before the change and =
the
> unmodified copy was moved into binfilter (and hopefully ;-) stripped
> from all code not used in binfilter later). As I wrote, this doesn't
> work for the GraphicObject and vcl, but we already used it for most of
> the bigger modules with a lot of code changes, so I don't expect a lot
> of room for improvement here.
>
> It should be mentioned that this approach only optimized the work from =
a
> maintencance cost POV, but it made things worse in other areas:
> binfilter becomes bigger each time when a copied module was added,
> increasing both build time and size of the installation set. And even
> the optimization for maintenance cost is incomplete as the resulting
> code duplication will require duplicated work in the future at least =
in
> case security leaks are found (been there, done that ...).
>
>> There is also a thrust to make converters more cleanly-separated and
>> having the plugin APIs work successfully for them.  Again, this is
>> the gist of it.  It doesn't seem too far from ideas that have been
>> floated around here, though.
>
> I'm afraid that talking about stuff like this without actually knowing
> the code will at best create confusion. So all I will say about that
> here is:
>
> We don't have converters, we have filters. And some of them are =
cleanly
> separated already, some aren't. As long as the latter aren't going to =
be
> reimplemented anyway, there wouldn't be much sense in investing time
> into improving their modularity.
>
> Is binfilter the next "bike shed" we are targetting?
>
> Regards,
> Mathias
>
--
ALG