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 Sat, 06 Aug 2011 11:46:25 GMT
Am 05.08.2011 19:44, schrieb Marcus (OOo):
> I hope that we still agree to keep the binfilters with our first Apache
> release. Otherwise we would deplay it more than IMHO necessary.

Correct, full agreement. Sorry to have not mentioned that, but of course 
for the first release it should stay added. Not sure about the current 
state, seems as if it is installed optional with default to false. I'll 
need to check that ASASAA (As Soon As Sources Are Available :-))

>
> After the first is done we can remove them for the 2nd official Apache
> version. While we do many dev builds on the way (hopefully, like it was
> with OOo) we can see if there are more problems that we have to take
> into account.

Agreed.

> In parallel we can make an announcement that the next version has
> a) only support for importing the old binary file formats
> - or -
> b) no support for import and export.
> Depends on what we want.

Agreed. I would just announce that it's the last version with binary 
filters, not really a neccesary to forbid writing from my POV.

Regards,
	Armin

> Marcus
>
>
>
> Am 08/05/2011 07:01 PM, schrieb Armin Le Grand:
>> Am 05.08.2011 18:47, schrieb Dennis E. Hamilton:
>>> 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.
>>
>> The current 3.2 version would be the last one to have both, how ling
>> will it be installable and runnable on evolving systems? Can only be
>> guessed, but usually it's another 7-8 years.
>>
>> I have no numbers, but how many people still have files in old formats?
>> With introduction ODF years ago it was preselected as the standard.
>>
>> When you load old files, change and safe them you are invited to use ODF
>> for the file save. The office was not even as widely spread as it is now
>> before ODF was added as default format, thus potentially much less
>> documents in the old formats were created, compared to ODF.
>>
>> I think something like old file formats have to be deprecated one day,
>> and in my opinion there was a quite long conversion/transition period
>> now. As others already mentioned, binfilter is not even installed by
>> default for 3.2 (if I remember correctly), and I have not seen any
>> complaints about that yet.
>>
>> To All: Does anyone use one of the old binary formats or knows anyone
>> who does actively nowdays? Please answer if you know about something
>> like that, this would be valuable input in this discussion.
>>
>> Regards,
>> Armin
>>
>>> 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).
>>>
>>>
>>> - Dennis
>>>
>>> -----Original Message-----
>>> From: Armin Le Grand
>>> [mailto:Armin.Le.Grand@me.com]
>>> 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
>>> 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
>>>
>>>
>>
>> --
>> ALG
>

--
ALG


Mime
View raw message