One of the central design alignments of the Configuration Manager configuration repository is to be as flexible as possible to be able to act as repository for configuration data of as many other already existing configuration formats as possible.
The configuration format that is used in the repository partitions configuration data into components. Components are collections of configuration settings. The settings that belong to a component are typically used together and may be interrelated. Often they are associated with a particular client application, software module or application domain. Components are identified by their name and grouped into a hierarchy of packages by using structured names, for example org.openoffice.Inet
Each component has a hierarchical structure. This structure is composed of nodes and properties. A node is a structural element that serves as container for other nodes and properties. A property is a leaf element of the hierarchy. It contains one or more values. Nodes and properties are identified by their name, which must be unique within their parent node. That allows it to reference any node or property by its component and path, for example, org.openoffice.Inet/Settings/ooInetProxyType
Other configuration systems have different configuration formats. The configuration data of other configuration systems is stored in the configuration registry using the APOC configuration format, but it has to be presented in the configuration format that the applications expect. A one-to-one mapping of the APOC format to the format expected by the applications is needed. The syntax mapping is silently done by the according APOC adapters. The only task remaining for template developers is to use the correct configuration path mappings when storing the configuration data in the configuration policy tree. These mappings are necessary to separate the config settings of the various client configuration systems in the central configuration repository. There are concrete mappings defined and considered by the adapters for the following configuration systems:
StarOffice/OpenOffice Registry (OOR, used for StarOffice and OpenOffice.org)
Gnome Configuration (GConf, used for Gnome applications)
Java Preferences (used for Java programs)
Mozilla Preferences (used for Mozilla)
The OOR key naming scheme is the scheme used for the APOC configuration repository, therefore, no adaptation work is necessary for this configuration system.
To transform a GConf configuration element into an APOC component and path, the following mappings are performed:
All GConf related components are prefixed with org.gnome.
/apps/<subdir>/... is mapped to the component suffix apps.<encoded subdir>.
/desktop/<subdir>/... is mapped to the component suffix desktop.<encoded subdir>.
/system/<subdir>/... is mapped to the component suffix system.<encoded subdir>.
/extra/<subdir>/... is mapped to the component suffix extra.<encoded subdir>.
/extra/<keyname>/... is mapped to the component suffix extra.
Keys not following the naming conventions are mapped to the component suffix ooc.<encoded subdir> if they feature a subdir and ooc otherwise.
/schemas/<keypath> is mapped to the component part schemas, and then the above rules apply for the rest of the key.
GConf key subdirs mapped to component parts are encoded to comply with component parts restrictions.
/apps/myapplication/sampleSub.Dir/sampleSetting becomes org.gnome.apps.myapplication/sampleSub.Dir/sampleSetting,
/desktop/sampleDir/sampleSub.Dir/sampleSetting becomes org.gnome.desktop.sampleDir/sampleSub.Dir/sampleSetting,
extra/sampleSetting becomes org.gnome.extra/sampleSetting,
/sample.Dir/sampleSetting becomes org.gnome.ooc.sample.Dir/sampleSetting,
/schemas/apps/gnome-setting/sampleSubDir/sampleSetting becomes org.gnome.schemas.apps.gnome-setting/sampleSubDir/sampleSetting.
To transform a Java Preferences node/key pair into an APOC component and path, the first three node path elements (or all node path elements if less than three are present) will be appended to java.prefs to form a component name and the remainder of the node path elements and the key will form the path. Only user preferences are considered.
node /com/sun/star/configuration, key someKey becomes java.prefs.com.sun.star/configuration/someKey,
node /com/acme/widget, key someKey becomes java.prefs.com.acme.widget/someKey,
node /sample.Dir, key someKey becomes java.prefs.sample.Dir/someKey.
To transform a Mozilla configuration element into an APOC component and path, the first element (assuming the name contains more than one) is appended to org.mozilla to form a component name, and the rest of the name is used as a node path. Preferences with only one element are stored in org.mozilla.ooc under their respective names.
mail.server.default.isSecure becomes org.mozilla.mail/server/default/isSecure,
sampleSetting becomes org.mozilla.ooc/sampleSetting.