On Tue, Jun 14, 2011 at 11:20 PM, Christian Lippka <[email protected]> wrote:
> I know we all wait for the code and the missing contributions from Oracle. > But no reason to plan ahead. > One think I like to see is the removal of the binfilter module after the > code has been contributed. > > Reasoning > > The binfilter module is a huge set of code duplicated from all application > modules and various high level > modules. It's main purpose is to implement load and store of pre xml binary > document formats > from the StarOffice era. Removing this code would spare us a lot of work > while we try to have our > first release buildable and running. > In how far would it "spare us a lot of work"? Granted, it is a large body of code, but it is code that by design has little dependency on the rest of the OOo code, so most times just compiles fine (even if it takes time to compile it). My understanding is that problems we will have to tackle to "have our first release buildable" have more to do with external dependencies and license issues than with building run-of-the-mill OOo C++ code. Do you assume that problems of the former kind lurk in binfilter? (Don't get me wrong, I'm all in favor of getting rid of binfilter, as it is a maintenance nightmare --- e.g., you need to duplicate bugfixes in the plain OOo code in the duplicated binfilter code. I just am not sure there is a reason to tackle the issue of getting rid of binfilter early on.) -Stephan
