Non-code extensions
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.
The Configuration Manager of OpenOffice.org has the same ability to scan an extendable set of folders as the Service Manager. So components can extend or change the OpenOffice.org configuration in the same way. Some configuration entries are used by OpenOffice.org to manage and access components (e.g. document filters or UI command dispatchers). So components in packages can be integrated by extending these entries in their package.
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.
The layering concept of the service and type registries and the configuration are the basic principles that create the power of UNO packages.
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.
Extendable Architecture of OpenOffice.org
As mentioned the Configuration Manager of OpenOffice.org has the same ability to scan an extendable set of folders so that components can extend or change the OpenOffice.org configuration by providing the necessary data (xcu) files inside the package. It is also possible to add new configuration settings by providing schema (xcs) files.
Obvious use cases for this feature are the mentioned component registrations e.g. for document filters or the overwriting of general configuration settings on the "all users" level. An administrator can customize the OpenOffice.org installation in his own account, take the created xcu files containing these customizations and bundle them in a package that he installs with "unopkg add --shared" each time he installs, reinstalls or updates OpenOffice.org. No need to edit the xcu files in "share/registry" by hand!
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.
