incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <Armin.Le.Gr...@me.com>
Subject Re: binfilter (was RE: OOO340 to svn)
Date Fri, 05 Aug 2011 11:33:41 GMT
	Hi *,

Binfilter can pretty simply be linked statically against the remaining 
dependencies (tools and below) and just stay there as a binary module. 
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 
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 
dangerous and may introduce errors.

Seen from today I see no reason at all to keep it; there are about 20 
versions of OOo/other derivates out there which support it and thus 
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 
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 
the rest by statically linking, keep it on the current version. Use the 
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 
countless versions which are capable to do the conversion

Thus I clearly suggest to do [2] now, enough ressources (memory, 
bandwidth, built time, ...) spent on it. Let's use the chance to cut 
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


Mime
View raw message