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]
