Forum OpenACS Development: Re: error on browsing to / on new oacs-5.8, pg-9.1, naviserv-4.9.9

The Tcl variables at the start of the config files are the common part which is typically needed for the configuration. The remainder of the config file is there as a documentation, what a user could change, what features are available and could be activated. In my opinion the best we can do is use the same set of Tcl and let people to copy this section if they want to move around between the servers. The documentational character is important: Look for example at the minimal config file of NaviServer [1], which is sufficient for non-db setups for NaviServer. On one hand it is nice, on the other hand, many people are lost when they want to modify the setup of the server.

If there would be a big outer "if" around one section for AOLServer and NaviServer, the documentational aspects suffer; people might be confused and change variable in the wrong part, miss dependencies between parts etc. If there are many ifs around the pieces which are different for the servers, this is also more work to maintain this large config file; having ifs around optional and commented out sections (e.g. for spooler threads) is strange; describing e.g. alternate ways to configure a server (e.g. per-server or global drivers in NaviServer, multiple servers or virtual servers in NaviServer, the configuration for various SSL drivers, etc.) is hard.

I've spent quite some time in the past to figure out why a certain change in a config file does not work as i would expect, finding often, that the parameter in question is not used at all by the server; Often it is not clear, what the defaults of some parameters are, especially when they change between versions of the server. That lead to the development of /admin/nsstats?@page=configparams (nsstats [2] is installed by the the installer in [3]) and the changes in NaviServer to track default values in the config database. A common burden is the legacy cruft and the legends documented in config files about necessary setups, which might have been important in ancient versions of the servers but lost its importance over the years, or which might be still useful for some old versions of drivers, modules etc.

Therefore i think, having a "nice", lean, cleaned-up config file is better than a single large one that tries to fit all purposes and legends.

Actually, i think the main problem is that many people "love" their old config files and do not dare to change anything, because they think that every change might endanger the stability of the system. In my experience this is rather an alarm signal. When people are not daring the touch anything in a code it is a good indicator that this piece of code is overly complicated and should be overworked.

-gustaf

[1] https://bitbucket.org/naviserver/naviserver/src/22487f6dbb7d7454c74244a57ab92256b0c3af64/simple-config.tcl
[2] https://bitbucket.org/naviserver/nsstats
[3] https://openacs.org/xowiki/naviserver-openacs

In regards to your summary paragraphs,

Therefore i think, having a "nice", lean, cleaned-up config file is better than a single large one that tries to fit all purposes and legends.

Absolutely. In that way, configuration stays accessable.

Actually, i think the main problem is that many people "love" their old config files and do not dare to change anything, because they think that every change might endanger the stability of the system. In my experience this is rather an alarm signal. When people are not daring the touch anything in a code it is a good indicator that this piece of code is overly complicated and should be overworked.

Yes. In my own case, I would always use the most current, not daring to try my old config on the new server version. Your indication is still the same.

Perhaps people would be less nervous if they saw that while aolserver/naviserv has its own config params, and that it is the loading of most (?) modules that adds additional params which would then be recognized in the config file, if they could see it's not just a monolithic, incomprehensible and uncontrollable mess (the perception of which we inherit from arsDigita days), but a fairly logical structure, they might be less nervous and more bold and confidently able to know and set their own params.