> I warn if the keyword isn't registered, ignore it and continue on.
>
> > In either case, it shouldn't bomb; it should just continue on to the
> > next line with a message to the user that it was ignored.
>
> One problem, the user never sees the message unless they are in the
> habit of running sendmail with the -v flag.
Shouldn't this output be returned to the user?
> Actually the newinfo command takes the input file, puts it into a file
> called <listname>.new.config and calls the config file loading
> procedure get_config(). Errors in get_config() result in an error
> message being pushed onto @config'errors. If get_config has any
> errors, it returns with a value of 1. The calling routine can choose
> to ignore, or look at the return value. do_newinfo() looks at the
> return value. If it is 1, it takes the error messages, and puts them
> into the majordomo reply message, unlinks the new config file, and
> returns to the main majordomo loop. If a 0 value is returned from
> get_config(), the old config file is moved to <listname>.old.config,
> <listname>.new.config is moved to <listname>.config, and get_config()
> is called again to parse the listname.config file removing all
> previous values for that list. Newconfig doesn't know, or care about
> the contents of the config file.
>
> > Another thing I don't like about having to submit a new
> > config file each time is the fact that I'll have to have
> > Majordomo send me the current config file, edit it (which
> > entails either writing it to a file, editing that, and
> > mailing the file, or else using my mailer's Reply command
> > and stripping off the leading ">"s on the whole file
> > as I edit my reply) and send it back. All to change one
> > little value.
> True, that's part of the reason my regression suite is so huge. Right
> now I am up to 26 keywords to control majordomo and reply. Maybe its
> time for a "config" perl script along the lines of approve?
But a config perl script doesn't help changing the values
remotely by e-mail, which remains a big pain in the neck.
> >jr> What happens when one module needs to influence the way another
> >jr> one operates?
> I validate each keyword/value on a line by line basis, but I have to
> check pairs of keywords as well.
> > What sort of interkeyword checking is there?
> Create the file <listname>.closed, now create the file name
> <listname>.auto. What happens?? Same problem with the config file. I
> bounce it if both auto and closed are defined since the person is
> telling me they don't know what the hell they are doing. I can see
> similiar conflicting options in many different areas.
It seems to me that this is the only thing standing in the way of
a set/show command syntax which could change one item at a time
instead of reloading the whole file. (As you probably have guessed,
I can't stand the idea of needing to reload the whole file each time.)
I would structure the code so that there is a separate validation
subroutine for *each* configuration keyword. Any cross-checks
would happen there, and conflicting options should be set accordingly.
For example, have a subroutine validate_closed and a subroutine
validate_auto. Validate_closed would check its parameters, and
also check the current auto flag. If the auto flag is on, validate_closed
would turn it off and *tell the requestor that it did so*.
Validate_auto likewise would turn off validate_closed and tell the
requestor.
In this way, new keyword validation subroutines could be dropped
in at any time. I would stil have a master default file which
gives default values and also defines which keywords are valid.
Any keyword which had a validation subroutine would be validated
and the new value accepted or rejected based on the subroutine's
return value. Any keyword in the master file which didn't have a
validation subroutine would accept any value.
> What I have is a genarl table driven parser. The function
>
> new_keyword(keyword, default, parse function, subsystem, [comments])
>
> adds a new keyword to the parser.
This sounds reasonable.
> Every value that is successfully parsed is put into the array
> %main'config_opts. The key is the concatination of the list name, and
> the config file keyword e.g. bblisaprivate-which bblisamoderate etc.
Should there be a separator between the list and the keyword, just
in case there were two lists, one of which is a subset of the
other, and the difference matched a keyword?
- Alan
---- ,,,,
Alan Millar amillar@bolis.SF-Bay.org __oo \
System Administrator =___/
MOSTLY harmless??!!
Follow-Ups:
|
|
