Re: [dev] paths configuration in v2.0.4
Allen Pulsifer schrieb: Hello Joerg, Thank you for your response. Just to respond further: The Current/Default distinction in that place was misguided. That should really be achieved via layering. I agree with this. There are other places in OOo where dynamically created keys have such significance. This is the only way to get mergeable lists of strings. That statement I can't agree with. The configuration registry is basically a database. It is not uncommon in database design to use arbitrary key names. But the name is never used as the value, because the two are semantically different. Similarly, in the OpenOffice.org registry, arbitrary key names would be used where required, with the key value used as the configuration settings. To get a mergeable list of strings, the key values would be merged, not the key names. You are right. In these special schema values are used as keys. That's more a trick then a good design. Interesting that there is an outside developer [you sound like somehwere who knows something about programming .-) ] which analyze the path settings configuration so deep. Here some explanations, why the current path configuration was designed this way ... I had to fullfill some requirements and the current feature set of our configuration does not allow so much possible solutions. a) As already mentioned by Joerg merging of string-lists (used before) isnt supported by the configuration. But we had to support layering/merging of path values. Otherwise an administrator (even an AddOn programmer) cant realy deal with paths). An example: AutoCorrect=$(share)/autocorr;$(user)/autocorr An administrator whish to redirect the user path to /home/allusers/autocorrect. But he cant do that without removing the share-path or defining it a second time. Only solution would be: AutoCorrect=$(share)/autocorr;/home/allusers/autocorrect From a database point of view; this design is not normalized. It contains redundant data. b) The only way to reach this goal was using of sets instead of string-lists. But on the other side the configuration does not know index based sets. They only allow to design named sets. But what's happen then ... you have to generate names for every path entry you whish to add. But you dont have realy usefull names available. A possible design would be: m_1 = path_value_1 m_2 = path_value_2 ... m_n = path_value_n But then you break a big rule of database design: using of unique keys as primary keys. Using this design would make it possible to define set's of paths containing the same value morethen once. Furtehr it wouldnt be possible for an AddOn programmer to remove specific paths. He has to know the internal number m_1 if he wish to remove path_value_1. Thats not possible ... because then OOo have to define and document a lot of unique key numbers which are stable for the future. c) So we found the trick to use path values as keys .-) It does not help for all uses cases (e.g. in case the same path can be defined using different variables ... as e.g. $(insturl)/share and $(share)) ... but if everybody follow some rules (e.g. using most suitable variables) it can be more usefull then the old schema. On the other side: please dont forget - the OOo configuration neverw as designed to be a database. It does not provide relations nor primary or secondiary keys. It's normaly a key-value oriented configuration only ... which was might be (realy?) tricky misused .-) Instead you need to know a list of unspecified key names. You don't suggest to hardcode com.acme.supertemplate into OOo, do you? I'm not suggesting this. The key names would identify the source of each path setting, but to OOo, the names would be irrelevant and it would not need to know them. OOo would enumerate all of the keys under org.openoffice.Office.Paths/pathname/InternalPaths, just like it does now, except it would concatenate the key values into a path list, instead of concatenating the key names. I tested the operation of path configuration in OOo v2.0.4 and wrote up instructions on how it can be configured by an administrator. Note these instructions are based on how the path settings have been tested to work, not how they are intended or documented to work. Comments are welcome. The instructions are located at: http://openofficetechnology.com/node/50 I read your documentation ... fine. I miss some details - but in general it's OK .-) But here some small corrections from me: = Three of these path settings, Backup, Temp and Work, are single paths which means they reference only a single directory. For these settings, the values in org.openoffice.Office.Paths are ignored, and only the values in org.openoffice.Office.Common/Path/Default and org.openoffice.Office.Common/Path/Current are used. That's not realy true. For those paths
RE: [dev] paths configuration in v2.0.4
I also submitted two bug reports. http://qa.openoffice.org/issues/show_bug.cgi?id=70688 http://qa.openoffice.org/issues/show_bug.cgi?id=70687 Thanks Allen, the developer responsible for this is currently on vacation but he surely will have a look when he is back end of next week. Thanks. I added one more: http://www.openoffice.org/issues/show_bug.cgi?id=70735 Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] paths configuration in v2.0.4
Joerg Barfurth wrote: 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. Apparently it was intentional that this isn't that easy. (Did I say that I was not involved in this project?) But you've hit the nail on the top. We have prepared for two ways of working with pathes: UserPaths can be overwritten like described here, InternalPaths are mergeable. So an admin that wants to write his own path as described by Allen and doesn't want to allow for changes mad by users just can set the value into the UserPaths and empty the InternalPaths (or keeps the share/template stuff). Then he can finalize both settings and he will be done. The new schema allows for nearly everything, it even allows to add new paths without changing the schema, one of the worst design bugs in the old schema. Allen, if you don't want to work with the InternalPaths, do it as I described. The UserPath should work exactly as you want (if I understood you correctly). Of course you can't extend (only overwrite) the path UserPath by extensions then but as Jörg explained you can't eat the cake and have it. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] paths configuration in v2.0.4
Allen Pulsifer wrote: I tested the operation of path configuration in OOo v2.0.4 and wrote up instructions on how it can be configured by an administrator. Note these instructions are based on how the path settings have been tested to work, not how they are intended or documented to work. Comments are welcome. The instructions are located at: http://openofficetechnology.com/node/50 I also submitted two bug reports. http://qa.openoffice.org/issues/show_bug.cgi?id=70688 http://qa.openoffice.org/issues/show_bug.cgi?id=70687 Thanks Allen, the developer responsible for this is currently on vacation but he surely will have a look when he is back end of next week. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] paths configuration in v2.0.4
But you've hit the nail on the top. We have prepared for two ways of working with pathes: UserPaths can be overwritten like described here, InternalPaths are mergeable. So an admin that wants to write his own path as described by Allen and doesn't want to allow for changes made by users just can set the value into the UserPaths and empty the InternalPaths (or keeps the share/template stuff). Then he can finalize both settings and he will be done. Hello Mathias. Thank you for your reply. The part that I think is more difficult than it should be is changing the value of an InternalPath. I would like to follow up with a specific proposal that will not reduce the functionality and will not make it any more difficult for package distributors, but will make it easier for system administrators. I hope to be able to post it later this week. Thank you, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dev] paths configuration in v2.0.4
Hello Joerg, Thank you for your response. Just to respond further: The Current/Default distinction in that place was misguided. That should really be achieved via layering. I agree with this. There are other places in OOo where dynamically created keys have such significance. This is the only way to get mergeable lists of strings. That statement I can't agree with. The configuration registry is basically a database. It is not uncommon in database design to use arbitrary key names. But the name is never used as the value, because the two are semantically different. Similarly, in the OpenOffice.org registry, arbitrary key names would be used where required, with the key value used as the configuration settings. To get a mergeable list of strings, the key values would be merged, not the key names. Instead you need to know a list of unspecified key names. You don't suggest to hardcode com.acme.supertemplate into OOo, do you? I'm not suggesting this. The key names would identify the source of each path setting, but to OOo, the names would be irrelevant and it would not need to know them. OOo would enumerate all of the keys under org.openoffice.Office.Paths/pathname/InternalPaths, just like it does now, except it would concatenate the key values into a path list, instead of concatenating the key names. I tested the operation of path configuration in OOo v2.0.4 and wrote up instructions on how it can be configured by an administrator. Note these instructions are based on how the path settings have been tested to work, not how they are intended or documented to work. Comments are welcome. The instructions are located at: http://openofficetechnology.com/node/50 I also submitted two bug reports. http://qa.openoffice.org/issues/show_bug.cgi?id=70688 http://qa.openoffice.org/issues/show_bug.cgi?id=70687 Thank you, Allen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] paths configuration in v2.0.4
Allen Pulsifer schrieb: 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. The Current/Default distinction in that place was misguided. That should really be achieved via layering. 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. Yes, getting and setting these values is much easier this way. The point of the change (apparently, I wasn't involved in this) is: - (Many/all) the affected settings are multi-valued (i.e. lists of pathes) and were realized as string-lists. - A string-list really is treated as a simple value by the configuration. Layer merging replaces the entire list rather than attempting to merge it. (Yes there are reasons for that.) - Some of the pathes need to be there for builtin features to work, if they are taken out of the list those features break. - Some of these 'internal' are determined at install time and so should be added to the lists by the layer merge. - Among the list, at most one path is special in that it is used for writing user changes. Determining which one that is from its position in a string-list that users can change arbitrarily is very fragile. (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. The separation addresses the last point above. 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. There are other places in OOo where dynamically created keys have such significance. This is the only way to get mergeable lists of strings. 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). That is slightly more complex than needed, because the project team didn't notice that the configuration supports 'extensible' groups, which act as sets of simple values. Or else it would have been possible to make groups with no members work. 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. That is the intent - these keys are required so it shouldn't be easy to clobber them. OTOH adding to or deleting from that list with a fragment of XML is now possible (and wasn't before). There even is a feature of the XML format that would allow completely replacing the contents of that set - but the implementation of that in OOo is somewhat incomplete and not active (oor:op='clear'). And you could easily replace the entire 'Templates' node, if it didn't have an attribute (mandatory='true') that is explicitly meant to prevent this. 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. OOo does not have a raw key-value pair API for its configuration. Instead you can navigate the hierarchy as objects. The object for the config node /org.openoffice.Office.Paths/Pathes/Path['Template']/InternalPath (yes, that is the correct and complete spelling of the key!) has a method getElementNames(), which
[dev] paths configuration in v2.0.4
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]
