On Wed, Jun 15, 2011 at 9:51 AM, Christian Lippka <[email protected]> wrote:
> 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. > I would state it somewhat differently: First, URE contains the code necessary to use UNO in any language (C++, Java, Python, ...); it just happens that for C++ it provides substantially more functionality than for other languages, including functionality that is more "convenient basis layer for OOo" than "pure UNO runtime." URE has a (so far) compatibly evolving interface. Second, OOo has a UNO-based interface. It consists of a large number of methods and data types, specific in nature to OOo, expressed in UNO. This interface, too, is (so far) evolving compatibly. A "clean" extension (regardless of language) makes use of the above two stable interfaces. A "dirty" extension, on the other hand, directly accesses functionality through channels other than those two stable interfaces. 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. A third part would be to reflect bugfixes in the copied-from modules to the copied-to modules. And that's where the costs of duplication kick in. I would prefer to avoid duplication. -Stephan
