From ooo-dev-return-3090-apmail-incubator-ooo-dev-archive=incubator.apache.org@incubator.apache.org Fri Aug 5 11:33:42 2011 Return-Path: X-Original-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3C82A73DA for ; Fri, 5 Aug 2011 11:33:42 +0000 (UTC) Received: (qmail 87074 invoked by uid 500); 5 Aug 2011 11:33:41 -0000 Delivered-To: apmail-incubator-ooo-dev-archive@incubator.apache.org Received: (qmail 86933 invoked by uid 500); 5 Aug 2011 11:33:39 -0000 Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-dev@incubator.apache.org Received: (qmail 86925 invoked by uid 99); 5 Aug 2011 11:33:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Aug 2011 11:33:37 +0000 X-ASF-Spam-Status: No, hits=-1.4 required=5.0 tests=RCVD_IN_DNSWL_MED,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gcaiod-ooo-dev@m.gmane.org designates 80.91.229.12 as permitted sender) Received: from [80.91.229.12] (HELO lo.gmane.org) (80.91.229.12) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Aug 2011 11:33:28 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QpIeA-0004w5-6y for ooo-dev@incubator.apache.org; Fri, 05 Aug 2011 13:32:58 +0200 Received: from 31.18.133.228 ([31.18.133.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Aug 2011 13:32:58 +0200 Received: from Armin.Le.Grand by 31.18.133.228 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Aug 2011 13:32:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ooo-dev@incubator.apache.org From: Armin Le Grand Subject: Re: binfilter (was RE: OOO340 to svn) Date: Fri, 05 Aug 2011 13:33:41 +0200 Lines: 112 Message-ID: References: <00e801cc51f4$f956b0e0$ec0412a0$@acm.org> <4E39844D.2090304@gmx.com> <012701cc520a$c7359570$55a0c050$@acm.org> <4E399EE4.5010700@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 31.18.133.228 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 In-Reply-To: <4E399EE4.5010700@gmx.net> 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