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

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.

One can certainly move towards a openacs configuration file based on tcl-vars only, that calls at the end the config scripts for the appropriate server. Sounds at first sight like a good idea.

However, this common part can address just the intersection of the functionality of the servers, and not the more advanced parts (e.g. spooler threads, writer threads, static gzip delivery, etc.). The server capabilities change as well the the setting of common parameters (we tend to use now more connection threads with naviserver, but wee still need rather less memory). If a user has to look into two different files, and a maintainer has to maintain extra files, some advantages fades probably. I am not sure, how much further development will happen with aolserver (which is a fine product, which serves with its frozenness perfectly the expectations of some sites).

I will personally not put effort this way (there are so many other things to do), but certainly everyone else can...

all the best
-gustaf neumann