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

another thing that could be done is factor the piece of the config file where the openacs installer puts the settings, and have the remainder -- which would have content specific to either naviserv or aolserver -- would call the factored piece, which would work with either.

what do you think?

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

I miscommunicated the shape of what I was thinking... yeah, the ifs would be very confusing.

Let me try to describe the idea more clearly:

right now, we have the openacs config file in $server/etc/config.tcl, and the openacs config in the naviserv source.

Each has a section of the variables the end user would change to get a basic set up, and these are at the top of each file.

Then, each file continues to their end with sections that are either preconfigured or commented out (like the ssls).

What I'm proposing is to simply split the etc/config.tcl at the point where the top parameters are, and then you have a file with only the commonly altered parameters, and another, with the rest. At the top of this file (non-common params) would additionally have a statement including the file with the common parameters.

The naviserv file would have this same include statement, replacing the common parameters.

Is that more clear? and if so, what do you think?

-Jim

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