Configmgr Refactoring/Design

Please view Configmgr Refactoring about analysis. This document explain configmgr new design and some discuss only .

Processing flow

We can divid configuration data processing into two phases:

OOo Packaging

Using tools and scripts, merger configuration files from sources to default configuration files which will be instaled into “$BaseInstallation/share/registry/”（as admin configuration file）. The result files can be XML file or binary file. Two tools (configmgr_tools /configmgr_converter ) and some scripts files be used in this phase.

Here have three steps:

(1) Merger .xcu files and .xcs files and .sdf into new schema configuration files.

(2) Replace some values in configuration files and do other procesings.

(3) Converter XML format configuration files in to binary configuration files.

OOo Running

Other module of OOo access and process the configuration data through the services of configmgr module.and we will discuss this at Processing flow in OOo Runing.

The relationship of new schema nodes in OOo running

New schema use OOo schema as standard, and adjust some places .

Node

compoents:

component:

component-data:

templates:

set:

group :

prop:

user-value:

default-value:

Attribute

package:

component:

node-type:

inserted:

removed:

extensible:

name:

readlnly:

nillable:

separator:

type:

additional:

[[Image:]]

Please note the inserted/removed attributes and user-value/default-value nodes ; and that will be describe below.

The configuration files placement after OOo install

It is same as the currently OOo implementation, and has some adjustment in some places.

It has two main directories too :

Default configuration directory ($BaseInstallation/share/registry/) 。

User configuration directory ($UserInstallation/user/registry) 。

And subdirectories with Multi-Linguistic:

$BaseInstallation/share/registry/en-US
                                     /zh-CN           
$UserInstallation/user/registry/en-US
                                   /zh-CN

Each language has a complete configuration data. It is our current implementation. Of course, it will occupy more disk space. Another plan we discuss at Multi-Linguistic.

Processing flow in OOo Runing

We can see the user configuration data file has a copy of default configuration data( admin configuration data) and user modification data.

By user-value/default-value nodes in user configuration data file, we can tell the value is user modification data or default data.

By inserted/removed attributes in user configuration data file, we can tell the node is user new data or user removed data or default data.

The below image is the processing flow about get configuration data from configuration data file. It is our complete solution after we discuss( It is not exactly same as our current source).

[[Image:]]The below image is the processing flow about write configuration data from configuration data file.As mentioned above,It is our complete solution after we discuss( It is not exactly same as our current source).

[[Image:]]

Merger multi-components

Now we define three types config item in “configmgr.ini” file.

1. 1. ARG_MERGER_COUNT：the count of multi-components merged files
   2. ARG_MERGER_MERGERNAME + n ：the file name of the n-th merged configuration file
   3. ARG_MERGER_COMOPNENTS + n ：the component name list which be merged to the n-th merger configuration file.

ARG_MERGER_COUNT=2
ARG_MERGER_COMOPNENTS0=org.openoffice.System;org.openoffice.ucb.Configuration
ARG_MERGER_MERGERNAME0=org.openoffice.MERGER0
ARG_MERGER_COMOPNENTS1=org.openoffice.Office.Commands;org.openoffice.Office.ProtocolHandler
ARG_MERGER_MERGERNAME1=org.openoffice.MERGER1