incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Le Grand <>
Subject Re: binfilter (was RE: OOO340 to svn)
Date Tue, 09 Aug 2011 18:43:26 GMT
Am 06.08.2011 19:45, schrieb Dennis E. Hamilton:
> " What does this show? Others behave much worse as we would do. If the
> first AOO release will be the last with binfilters and we assume a
> runnalble/installable state of 5-10 years (depending on OS, unforseeable
> progress, etc...) this will be fine from my POV."
> My concern about this rationale is that those of us who see no problem are making a likely
irreversible decision that impacts those who do and may not even be aware of what we are doing.

Can never be excluded, we simply have no numbers. Remember, this means 
we also have no numbers about how many people use it. No complains when 
not installing it by default hints to no users.

OTOH we have numbers about time, space, bandwidth, buildtime 
consumptions of binfilter. We know that it needs to be looked after. 
Michael Stahl pointed to probable security relevant stuff in the old 
binfilter parts (I guess he's right). We know that it builds with a lot 
of warnings. Trying to remove those is ambitious, but OTOH dangerous, 
may add errors to binfilters. Errors may be added by changes to 
underlying modules with nearly no chance to find them. Even changing the 
compiler may add unnoted errors.

In short: It does not come for free to simply keep it.

All in all:

Binfilter has done it's duty. It has allowed to do changes to the 
internal core class hierarchy and more. It has allowed to have a 
transition phase. Let's let it go...

> With regard to consumption versus production, I agree that it is easy to stop supporting
production when no native consumers are likely to be available any longer and the
document model evolves to support expanded functionality of further ODF specifications.
> So if we propose to retire binfilters, we need some way to make it clear that is happening
and what the workarounds are for someone who finds themselves in need.  And we definitely
need to keep it in a form where someone could revive it at a later time, even if only part
of some sort of document-forensics and -recovery/conversion effort rather than integrated
into future releases.

Sure, agreed.

> This is not the last time we will need to deal with this (and the same fate could eventually
befall the native format currently supported by
> Also, if there are available specifications, whatever their quality, we probably need
to see to their preservation as well.
>   - Dennis

View raw message