Some weeks ago I changed the xslt filter code to support the deployment of xslt based import and export filters as extensions, making the awkward XML filter dialog somewhat obsolete. This change became a part of OOo 3.0 and so I'm glad to announce that we have another area of development where extensions offer a fast, easy and flexible way to contribute to the OpenOffice.org project. The growing number of features that can be provided as extensions made me look back a bit and have a little reminiscence.

More than ten years ago (in 1997) the StarOffice development team started to work on UNO, our component technology that enabled us to make StarOffice (and later OpenOffice.org) extensible. At that point in time of course nobody thought about “extensions” like we have them today, but the idea to replace or extend existing functionality (“services”) using configuration or deployment means was one of the main design goals of UNO and UNO APIs. My own part of the API development was the Application Framework API. By its very nature a framework itself does not provide a lot of functionality directly, but instead of this offers APIs to plug it in. So I spent weeks and months together with Michael Hönnig, the former OOo API project lead, to design small and flexible APIs that allow to bind external UNO components to the framework at different places and in different ways. Especially our Dispatch API with its capability to chain DispatchProviders offered a simple, easy-to-implement way to bind external code to commands in the OOo GUI, either existing commands or completely new commands that no code inside OOo could handle. This API was finished and published in 1997 and without some minor complaints I still like it the way we made it. Today it's the backbone of all GUI based extensions and it has proven its simplicity and versatility on many occasions.

The idea of GUI extensions came up nearly at the same time where the UNO team finished their work on “ UNO packages” that we nowadays just call “extensions”. That was somewhere in 2002, on the OOo 1.0.x code line (I don't remember the exact value for “x”). The UNO team and the framework developers though about UNO packages with GUI integration (“like in Mozilla”) and the result were OOo Add-Ons. They brought together UNO packages, the Dispatch and other Framework APIs and some configuration magic. At the end of 2002 we had the first running version of such an Add-On, an extension that could be installed on the command line using the “ pkgchk” tool that was replaced by the “unopkg” tool later. This Add-On integrated itself into the OOo menu bar and had an own tool bar. It was just a demo, so it didn't contain any important functionality. But it worked in OOo 1.1 and it still runs 6 years later in OOo 3.0! Try that with any Firefox extension...

In 2005, at the OOoCon in Koper, we discussed the idea of an OOo extensions repository. It took quite some time to define what we wanted, find developers implementing it and a place to host it – but finally, nearly two OOoCons later, in August 2007 our extensions repository went online. We started with extensions implemented in Java, Basic or C++, meanwhile we also see Python extensions and non-code extensions for templates and dictionaries and perhaps more in the future. And now also xslt. So back to the start of my blog.

Many developers can work with xslt and perhaps some of them might be interested to use them for conversions to or from ODF formats. OOo allows to use xslt as filters since quite some time. Now in OOo3 it will be easy to package them as an OOo extension containing the transformation together with some configuration files. This can be done decoupled from the OOo build process and release cycles and so offers a very fast and easy way to contribute to the project. I've put some documentation about how to create such an extension into our wiki, together with a sample xslt filter extension. A next step (planned, but not scheduled yet) is to change the XML filter dialog to export extensions instead of jars so that no manual editing of configuration files would be needed anymore to create an xslt filter extension. If someone is interested to work on that – just send a mail to the “ dev” list of the framework project.

I hope developers will enjoy this new feature and users will enjoy the new filter extensions that hopefully will arrive at our repository.

BTW: while working on the sample extension I updated and consolidated the documentation about filter development in our Developer's Guide.