Passive Component Registration
UNO components in the various language bindings (dynamic libraries for binary/C++ UNO, jars for Java UNO, etc.) have mechanisms to actively report information about the services and singletons they offer (exported symbol
component_writeInfo for dynamic libraries,
public static __writeRegistryServiceInfo method for jars, etc.). This active component registration has various drawbacks:
- Calls to actively register the components (
regcomp) need to be made in carefully crafted environments, ensuring that the relevant UNO components can actually be loaded and their code executed. Especially for Java and Python components, this is nontrivial.
- At OOo build time, when a
services.rdbis assembled in
- At OOo installation time, when bundled extensions that contain UNO components are registered.
- At OOo run time, when extensions that contain UNO components are registered or revoked.
- At OOo build time, when a
- Loading the UNO components to actively execute their code can be time consuming (especially if the components' functionality is not otherwise needed, like when assembling a
services.rdbat build time).
Therefore, it is sought to replace active component registration with a passive approach, where a UNO component is accompanied by a representation of the relevant information that can be obtained without running the component's code.
An XML Format
The canonic choice for representing such information these days is XML. The necessary information is encoded as follows:
An XML document encoding information about multiple UNO components (i.e., corresponding to a
services.rdb) has a root element with local name
components and namespace URI
components root element contains zero or more elements with local name
component and namespace URI
http://openoffice.org/2010/uno-components, each with an attribute with unprefixed name
uri, the value of which is a URI (in OOo-internal form) denoting the relevant UNO component (and which may be a
vnd.sun.star.expand URL), and an attribute with unprefixed name
loader, the value of which is the name of the relevant UNO service with which to load the component (e.g.,
component element in turn contains zero or more
service elements, followed by zero or more
Each element with local name
singleton and namespace URI
http://openoffice.org/2010/uno-components has an attribute with unprefixed name
name, the value of which is the name of the respective service or singleton.
(The information provided by active component registration contains redundancies that are dropped from this XML format. For one, UNO components are listed in an
IMPLEMENTATIONS section and each service and singleton is again listed in a
SINGLETONS section. For another, each singleton specifies the service implementing it.)
There was already a somewhat similar textual format for
regcomplazy in use, which however was based on ini-file syntax (but with irregularities, containing lines that do not match the
key=value format) instead of XML. This has been superseded by the approach described here, and
regcomplazy has been removed.
As we will see later, within the OOo build system there are also XML files describing single UNO components, and which have a
component element instead of a
components element as their root element, but otherwise use the same structure as the above XML format.
XML at Run Time
There was a choice whether to either take the XML files and inject them into registry-format
services.rdb files (i.e., to still call
unopkg at build resp. installation time), or to use the XML files directly at run time. I decided for the latter.
configmgr re-write showed that it is acceptable performance-wise to read a handful of XML files during OOo start up, using an XML reader specifically written for that task. So it should be acceptable to replace the existing registry-format
services.rdb files (for a start, the URE layer
services.rdb and the basis layer
legacy_binfilters.rdb) with XML files.
The advantages are easier and potentially faster creation (no need for
regcomp like code any more), and easier manipulation (due to the textual format). Also, the registry format has a known design defect, in that it cannot handle arbitrary combinations of key names.
Work in Progress
Work is done on CWS sb129 , currently as a stack of MQ patches:
simpleregistry-cleanup cleans up the
stoc/source/simpleregistry code so that subsequent patches can better modify it.
xmlreader extracts the
XmlReader code from
configmgr to a new
xmlreader URE module, so that it can be reused from
stoc. An open problem is how to version its C++ ABI (currently done via symbol visibility, which does not allow for versioning).
textualservices extends the implementation of
stoc/source/simpleregistry, so that it can internally also read XML files in addition to registry files, and present them to its clients as if they had the structure of registry-format
services.rdb files. This appeared to be the simplest approach for now, given how deep the knowledge about registry-format files is rooted in the code base (see, for example, the functionality in
cppuhelper/bootstrap.hxx that bootstraps a UNO environment based on
rdb files); it is still subject to change, however.
passive replaces the active registration of all of OOo's UNO components with passive registration. The resulting XML files are still called
services.rdb etc. (instead of, say,
services.xml), mainly because [
ure/source/README] declares the URE
services.rdb as part of the published URE interface (acknowledging only its existence, not its internal format, and especially warning against registering anything into it).