Java Desktop System Configuration Manager Release 1.1 Developer Guide

Appendix A Configuration Path Mapping

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)

The OOR key naming scheme is the scheme used for the APOC configuration repository, therefore, no adaptation work is necessary for this configuration system.

Gnome Configuration (GConf)

To transform a GConf configuration element into an APOC component and path, the following mappings are performed:

Example A–1 Gnome Configuration

Java Preferences

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.

Example A–2 Java Preferences

Mozilla Preferences

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.

Example A–3 Mozilla Preferences