I'm looking over the new Path's configuration and it seems to me the
implementation is awkward and does not follow the usually configuration
paradigm.
In OpenOffice.org v2.0.3 and prior, paths were configured via
org.openoffice.Office.Common/Path/Default and
org.openoffice.Office.Common/Path/Current. This mechanism followed the
usual paradigm of key-value pairs, where the key would tell you what
information you were looking for, and the value would tell you the setting.
So for example, if you wanted to know (or set) the default value for the
template's path, you would look at org.openoffice.Office.Common/Path/Default
and retrieve (or set) the value of the key Template.
This system had several advantages:
(a) If you want to know or set the value for a particular key, you can
access it by key name.
(b) The value for a key could be overridden by a short fragment of XML, at
any configuration layer.
(c) The key-value pairs could be stored in a database, in a traditional way.
The new configuration mechanism for v2.0.4, as documented in
http://specs.openoffice.org/appwide/options_settings/OOoPaths.odt, replaces
the usually key-value pairs with the following:
The configuration settings were moved to org.openoffice.Office.Paths.
Within this tree, there is a node for each path (Template, Dictionary,
Basic, etc.). For each path:
a. There are two key-value pairs, UserPaths and WritePaths, that work as
expected.
b. There is a third subtree, InternalPaths, that contains a set of what
could be considered keys. These keys work completely differently. For the
keys in the InternalPaths tree, the key is the value and the value is
completely ignored. For example, for the Template path, InternalPaths
contains a key named $(insturl)/share/template/$(vlang). (I've simplified
it slightly by calling this a key; its actually not even a key, it's a group
of type MultiPath that's named $(insturl)/share/template/$(vlang) and
forms another subtree that contains a single key Unused that is completely
ignored. Thus the name of the group or subtree is what serves as the value,
and both the key within this group and its value are ignored).
This has more than a few disadvantages. First, as far as I can see (but
please correct me if I am wrong) it is not possible to write a short
fragment of XML that overrides the value of this setting, therefore making
true layered configuration impossible. Second, it is not possible to look
this value up or set the value by name, instead, to look the value up, or
set the value, you have to already know the value, i.e., the value is looked
up or set by value and has no independent name.
The new path configuration could have been implemented using the key-value
paradigm, and maintaining all its advantages while still accomplishing the
same goals, as follows:
InternalPaths would contain a set. Each component that wishes to set an
InternalPath would create a key (also known as a node) within this set using
its own name. For example, the base application would create a key called
org.openoffice.Office.Paths/Template/InternalPaths/org.openoffice.app
An add-on called SuperTemplates by acme.com might create a key called:
org.openoffice.Office.Paths/Template/InternalPaths/com.acme.supertemplates
The value of these keys would be string-lists, just as before. The
multi-layer configuration parser would take these keys and merge them
together into one long string, just like it does now, except that it would
merge the key values, not the key names.
The advantage of this configuration method is that it maintains the
key-value paradigm. The value of a key can be looked up without already
knowing a value. If an administrator wanted to override the value of
Template path used by the application, he/she could do so with a short
fragment of XML that simply replaces the value of
org.openoffice.Office.Paths/Template/InternalPaths/org.openoffice.app. This
XML fragment would look just like every other XML fragment used to configure
OOo. Similarly, for each add-on installed, an administrator could customize
the installation by only knowing the names of the components, not the values
of its paths.
If this is a simple change to make, I would propose it be adopted for v2.1.
At minimum, I believe to the extent possible the key-value paradigm for
configuration should be maintained. There was no reason to break it in
order to allow multiple components to set paths, and by breaking it, some
things that should be simple, both to do and to understand, become much more
difficult.
Sincerely,
Allen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
