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
