+1 Valuable analysis. Thanks Christian. And an ideal way to look at the refactoring.
- Dennis I don't know why it can't be in the same SVN repository though - there is nothing magical about SVN trunk or trunk even being at the top (of the project's chunk of the global SVN) except by convention. -----Original Message----- From: Christian Lippka [mailto:[email protected]] Sent: Wednesday, June 15, 2011 00:52 To: [email protected] Subject: Re: [discuss] remove of binfilter module Am 15.06.2011 00:29, schrieb Greg Stein: > On Tue, Jun 14, 2011 at 17:20, Christian Lippka<[email protected]> wrote: >> ... >> Proposal >> >> I suggest to remove the binfilter module after the code has been provided >> under the AL. >> Therefore we have it inside the SVN and could re activate it later. >> Preferable as a separate >> extension. > I'm unfamiliar with OOo's extension system. How hard would it be to > add "import OLD format $FOO"(*) as an extension? In a way the binary filter for old StarOffice formats are already an extension. The Problem is that they are not build independent of OpenOffice like other extensions. Therefore they add a lot of code to the core codebase. I do not know if apache allows to have multiple svn repositories for each project. But moving binfilter to a separate repository and refactor it to become a build independent filter makes sense. Since it does not alter any core internal stuff, it is also something that one or more developers can work on without interfering with ongoing core development. The following text is more directed towards developers so let me restate my high level goal again and all non devs can skip the last part :-) I do not want to remove the feature to load old documents forever. I just want to ease the burden of maintaining the OOo source code and help us get this baby flying sooner and not later. If we have resources and time for this than it will be re added later. But such work should be prioritized as soon as we have something usable to show. Some background on the OOo extension system. There are multiple levels of extensions. An extension is everything that can be optionally installed using the extension manager. An extensions communicates with the office code by using the UNO API available. This can be used from all languages where we have a UNO bridge, f.e. java, python etc. Preferred extensions are extensions who only use the UNO API. Those extensions are working with every OOo build that did not break the API compatibility. The next level of coupling for extension is a c++ extension that uses the Uno Runtime Environment (URE). This is a set of low level modules with defined interfaces that in the past stayed compatible during minor version changes. The highes level of couping for extension is a c++ extension that directly links to any OOo module above the URE level. Those extensions only work in the specific OOo version they are compiled for. Binfilter is kind of the later. It is something special as it does not directly use the UNO API but the XML format to communicate with the core Office. Therefore it is possible and IMHO desirable to put binfilter and all modules binfilter use in a separate repository that builds an optional extension that can be used in any upcoming OOo version. Usually code duplication is the root of all evil. In this case it is justified as there should by definition be no more work done on the binary filters as the feature set of binary filters is locked. In the past there where only two types of work done in the binfilter module. The small part was of course to fix security issues found in the filter code. This will obviously have to continue. The major work caused by binfilter was to adapt it to changes to underlying modules. This was not only wasted work but also had the chance to introduce regressions. > If it can be implemented "soon" or "later" as an extension, then it > seems moving this in that direction makes sense *regardless* of the > binfilter problems (ie. as a way to modularize). And that you could > start out by tossing everything on Day Two, then letting the > "interested devs" bring the feature back as a set of one or more > extensions. > > Cheers, > -g > > (*) assuming my understanding is that binfilter is *only* about > importing archaic formats >
