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
* 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
* Default value should be available near each parameter, to make it
easy for the administrator to see if the parameter has been
* Default value should be machine-parseable for use in web-based
* 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
The most tricky parts are probably how to represent allowed values in
a way that is both understandable for users, and machine-parsable.