Re: configuration

# Regarding config and hypermail
#
# Is there any good reason why all the labels in the configuration file are
# prefixed with 'hm_' ? In my eyes this only makes the labels harder to read. I
# vote for their removal. I also vote for that hypermail should be able to
# generate an example config file (or shipe one in the release archive)
# including detailed comments so that it easily can be edited to do what you
# want. I'd like to see boolean options handle 'Yes/No' or 'On/Off' for
# enable/disable instead of the weird numericals it does today.

First the config variables: I have no great issue eithere way other than it may affect sites already using them (and I'd need to make some serious documentation changes ;-)) If others have a problem with the hm_ prefixes I can change those. On the table.

When you say generate an example config file are you meaning that you would supply command line options and it would spit out a config file suitable for running ? or simply a help feature that generates a config file that the user then needs to fill in ? It was planned that a few example config files will be shipped to ease in the process and one would be a documented template.

And yes it is a bit confusing as to what is numeric and what is string based config items but that really is a documentation issue since users will still need to determin what is a yes/no and what is a string option. ;) A better commented template might solve this.

# Futher, I don't like that many interesting options to hypermail are set at
# compile time. One executable can possibly be used for a series of different
# mail list archives and settings.

In the current version ALL compile time options have associated configuration file entries.

# There might be a reason to check the over-all handling of command line
# switches, environment variables and the config file. Adding new settings are
# messy as it is solved now, when it shouldn't have to be.

Yes it is. This is what I found confusing. Usually the command line options override the options in a config file. Well, with hypermail it gets the environment variables, then the command line options and then the config file settings. This is because hypermail needs to get the hypermail config file from the command line before it can set and config file variables....

# Also, keeping a lot of the settings as (large) variables in the main()
# function, passing them as separate arguments to the functions that need them,
# is not nice. More parameters are likely to appear and every time that happen,
# another argument to the functions that need that data is gonna have to get
# added.

6 of one, half dozen of another... I agree that it would be easier if they weren't passed all around. I probably won't worry about that until I get the first merged version out.

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: kent_at_landfield.com             http://www.landfield.com/
Email: kent_at_nfr.net                   http://www.nfr.net/
Please send comp.sources.misc related mail to kent_at_landfield.com
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/