Each configuration parameter in hiveconf has several pieces of information: * The current value - this is currently set in the .hconf files. * The default value - this is currently set in our code, where it's not available neither to system administrators that want to know if the setting has been changed, nor to other tools that want to know the default value (web-based administration tools, etc.). It would also be nice to be able to auto-generate documentation with the default value listed, and that is currently not possible without parsing the python code.. * Documentation - this is currently, if the developer remembers to do it, available in TAG. There are also comments in the .hconf. There's no guarantee that the comments in .hconf files correspond to the documentation in TAG. As with the default value, it would be nice to write the documentation in one place, and then auto-generate configuration information to be placed in the TAG. * Allowed values/type of parameter - this is currently, in some cases, documented in comments in the .hconf and in the TAG. For a web-based administration tool to work well, it would need to now if the value is a string, a string list, an integer, etc. It would also need to know if a string value has a limited set of values (example: /appservergroups/rdp/<group>/sound), if an integer value has a limit on the range, etc. This information would also be interesting to list in the TAG. Regarding the default values, the policy until now has been that they should remain in source code to make sure ThinLinc runs without configuration files available. Currently it doesn't work, btw - vsmserver and vsmagent starts, but vsmagent fails when trying to create a session. In my opinion, it would be better if the default values were available to system administrators and documentation generation systems. Being able to run ThinLinc without configuration files to me sounds like a corner case we don't need to support. So, what's the best way to implement this? I can see several requirements: * Documentation should be available near each parameter (in the .hconf files). It should be easy for the administrator to edit the .hconf files, which means some documentation for each parameter need to be available in the .hconf. * It's not neccesary to list all documentation for a parameter in the same .hconf as the parameter - that might make it hard to navigate due to the large files that will be the result. We do however need to ship the full documentation for all parameters in machine-parseable form to make it available to web-based configuration interfaces. * Default value should be available near each parameter, to make it easy for the administrator to see if the parameter has been modified. * Default value should be machine-parseable for use in web-based configuration interfaces. * Allowed values should be available near each parameter, to make it easy for the administrator to edit the file. * Allowed values should be machine-parseable for use in web-based configuration interfaces. The most tricky parts are probably how to represent allowed values in a way that is both understandable for users, and machine-parsable.
