It strikes me that it is better to refactor and have the binfilters be independently pluggable without the code dependency issue you mention. That seemed better when I saw it discussed for LibreOffice as well.
My concern is from my background in document management systems. There may be conditions that prevent conversion of the files. In those cases, it is necessary to maintain some way to continue access to the documents using newer clients, at least until the bits of the documents can't be preserved any longer. Whether these could be separate plug-ins outside of the main distro(s) is a different question. - Dennis -----Original Message----- From: Christian Lippka [mailto:[email protected]] Sent: Tuesday, June 14, 2011 14:20 To: [email protected] Subject: [discuss] remove of binfilter module Hi all devs, 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. Caveats While replaced by xml formats way back in 2002, there are still documents in the binary format around so at least loading them may be a requirement for some users. There is a consensus that only the import part is needed, but removing just the export part is tedious work so no one has done it yet. 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. Technical Background The binfilter module was created by copying all application code that was involved in loading and storing the binary document format. That code was then striped down to only handle the persistence part including the streaming operations. During import, the complete document was streamed into memory using the old implementation. Then the binfilter copy of the xml filter transformed the in memory model into a temporary OpenOffice.org xml stream. This stream was then imported by the current document implementation. The reason for the invention of binfilter was the high coupling of the binary format and the model implementation. Changing the actual implementation started to get harder as the binary document format was nearly a 1:1 memory dump of the model. So putting all the binary stream operators aside enabled us to make drastic changes to the model implementation. While the binfilter only communicates with the office code using xml, it still is highly dependent as it uses some low level modules. Therefore each time those modules change, the binfilter module must be rebuild. Some developers, including me, proposed to have all needed modules cloned into the binfilter module. To have a completly independent extension that does not need to be build when the office itself is build. Christian.
