Revision as of 12:46, 10 October 2006

UNO Packages: Basic Principles

The OpenOffice.org extension deployment concept based on UNO packages is not limited to code, it also allows to install other things like templates, autotexts etc. in handy packages. Here's a short explanation how this basically works. It is targeted to end users and administrators. If you want to learn more about UNO you can check our UNO wiki or the web pages of the UDK project.

UNO packages are more or less zip containers with some additional data and meta data describing its content. If such a package contains a UNO component (written in Java, C++ or Python) this component must publish its functionality to become usable for OpenOffice.org. In UNO based development a defined set of functionality is called a "service". So a component implementing such services must tell the world how they are named by providing a registry file (services.rdb) containing this information and probably another registry file (types.rdb) in case it uses and defines some new UNO types. Other components that don't implement such concrete services use extendable configuration entries to make their existence known to OpenOffice.org or to bind themselves to events that happen in the program.

UNO packages can be deployed by the built-in Package Manager GUI (“Tools – Package Manager”) or by the command line tool “unopkg” that is located in the OOo program folder. The latter also allows to deploy a package not only for a single user but all of them by using the “--shared” parameter. When packages are installed their content is copied to some well defined though private places below “share/uno_packages” or “user/uno_packages”, depending on the scope of the package installation (whole installation or single user). "Private" means: don't write any code that relies on the particular structure of an unpacked UNO component, access to unpacked files must use a defined API that handles the details for the caller.

When now OpenOffice.org uses its Service Manager to look for available UNO services it will scan not only the service registry (services.rdb) in its program directory but also all registry files inside the “uno_packages” folders. Installing and removing components is done by adding or removing packages with unopkg, the global registry files are not touched at all.

Not every

Extendable Architecture of OpenOffice.org

The ConfigManager of OpenOffice.org has the same ability to scan an extendable set of folders and so components can extend or change the OpenOffice.org configuration in the same way, just by providing the necessary schema (xcs) or data (xcu) files inside the package. Of course you can even create packages that contain only configuration files but not any code components. This way it's possible to customize OpenOffice.org by handy packages.

We could have extended other components inside OpenOffice.org that retrieve content from files (e.g. the component that manages document templates or the component for autotexts) in the same way, but we decided to reuse the already available capability of the ConfigManager and utilize it for other purposes. The idea is to make the list of folders to scan for content a configuration item (we call this a “multipath”) that can be extended by packages. This looks similar to the old feature that such pathes can be changed in “the Options” Dialog, but it's much easier to use and handle. It's easier especially for administrators that couldn't use the dialog and instead had to edit the configuration files by hand each time they deploy a new installation.

The old configuration schema for path settings wasn't extendable. Each configuration layer could just overwrite the layers below, but it wasn't possible to merge entries from different layers to one single multipath. So beginning with OpenOffice.org 2.0.4 the configuration schema for paths has changed considerably to support this merging process. We also kept this old feature for compatibility reasons and migrate its settings to the new data.

If you look on the “Path” settings in the “Options” Dialog in OOo2.0.4 you will notice that not all parts of the multipaths are shown here. The reason is that the dialog shouldn't expose anything to the user that is not under his control, thus you don't see the default folders from the “share” directory and you don't see any folders from packages, just the default folders from the “user” directory and any other folders that might have been added before. The path extensions provided by packages are completely under control of the PackageManager.