In message <9311072144.AA15656@mycroft.GreatCircle.COM>, Brent Chapman writes:
> Alan Millar <amillar@bolis.sf-bay.org> writes:
>
> # That's one of the problems with the attempt to keep a strangle-hold
> # on all possible configuration values. The quick answer is (1) accept
> # and ignore keywords that aren't recognized (so if a module
> # is re-activated later, you still have the settings from before) or
> # else (2) ignore the keyword completely. 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.
>
> I concur with this. I like the general Internet principle for
> protocol design that goes something like "be careful of what you
> generate, but generous in what you accept". That principle implies
> that, if you get a keyword that you don't recognize, you should
> probably just ignore it (perhaps with a warning, but often not). Look
> at how well mail headers work because of this principle...
It warns for invalid values, and doesn't put them in the config array,
but bad keywords have no other effect.
> # This is another thing in favor of a SET/SHOW syntax which updates
> # one item at a time. I would think that shouldn't be too hard
> # to implement. Your proposed "newinfo"-like command that reads the
> # whole config file is mostly a read loop around code that does one
> # setting at a time, right? Strip off the loop and you have the SET
> # command.
> #
> # 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. Sending a single new value when I don't care
> # what all the existing other values is so much simpler if
> # there is a command to set a single item.
>
> I concur with this as well. There are times when both interfaces
> (i.e., "set a single item", and "reset everything") are useful; I'd
> like to see both supported.
I think I have a simple mechanism for reconfiguring without having to
specify all options. The steps that take effect when validating a new
config file are:
1) Save the contents of the config file to listname-test.config
2) Load the config file for the pseudo list listname-test.
a) If there are errors in the config file listname-test,
report the errors and unlink listname-test.config.
3) If the config file listname-test.config was successfully parsed,
rename listname-test.config to listname.config
4) Clear out all entries in the %config array that deal with listname
5) Load the listname.config config file into the %config array.
All I have to do is eliminate step 4, and regenerate the
listname.config file with the new information. I already have a
function that will pretty print/rewrite the current contents of the
config array for a given list.
> # I personally don't think every value needs to be validated like
> # you are proposing. Let the routine that wants a config item
> # validate it at run-time, and do whatever the code defaults to if
> # it isn't there or is invalid. Then the whole thing is a non-issue.
>
> I'm kind of ambivalent about this. I can see good arguments both
> ways. I guess it will come down to whether or not the validation code
> is more pain than it's worth.
>
> Ick. I hate "foo1", "foo2", ... interfaces for multi-line data.
>
> I think what John and I have agreed on is a "<<" interface for
> mutli-line data that will be implemented in the general config parser,
> so it can be used for any option (not just options that are flagged as
> "possibly multiple lines"). I.e., you could do:
Actually, I require that the type of the item be *_array otherwise <<
doesn't work. I see this as being part of the validation routine. My
parser shouldn't return an array string unless the person defining the
keyword requests an array string. Of course
keyword = value
works since it is the degenerate case where the array is one element
long.
> foobar << EOF
> line 1
> line 2
> line 3
> EOF
>
> or
>
> foobar = one-liner;
No need for the `;'. This isn't `C' or Perl 8-).
> # Just so you know, I don't want to down-play all the effort you're
> # putting into this; I guess we are just coming from different points
> # of view. I've been envisioning a minimalistic sort of config file
> # that just holds whatever the list manager wants, and it's up to
> # the subroutine to pull out whatever it wants. After all, it's
> # the subroutine that *uses* the config items that has the last
> # word on what's valid and what isn't.
>
> This has been my philosophy in building Majordomo, as well. I'm
> willing to give John's validation code a chance to prove itself,
> however. On the other hand, if it proves to be too complicated, and
> more trouble than it's worth, I think it should be pretty easy to
> strip out the validation features of the config file stuff.
Actually it is very easy. You just kill the line that calls the
validate routine from the table.
Part of the reason for the validation code is that it REQUIRES the
keyword creater to document (to the parser) what is expected as a
value. This documentation then is used to provide information to the
user about the type of data that is correct and will get the
correct/expected response. This way a minimum amount of info is
required to be provided before things will work.
Also, if every function has to do its own validation code, why not
provide the validation code as a library routine that will be tested,
and can be optimized, that way everybody doesn't have to reinvent the
wheel. The current types that are supported are:
absolute_dir -- A root anchored directory
absolute_file -- A root anchored file
bool -- choose from: yes, no, y, n
enum -- One of a list of possible values
integer -- an integer (string made up of the digits 0-9,
no decimal point)
regexp_array -- An array of perl style regular expression with
leading/trailing /'s
restrict_post -- a series of space or : seperated file names in which
to look up the senders address
(restrict-post should go away to be replaced by an
array of files)
string -- any text up until a \n stripped of
leading and trailing whitespace
string_array -- an array of strings
word -- any text with no embedded whitespace
To be implemented are:
float -- a floating point number with decimal point.
float_array -- an array of floats (for load average limitation)
Future discussion of this should be done in majordomo-workers.
-- John
John Rouillard
Special Projects Volunteer University of Massachusetts at Boston
rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480
===============================================================================
My employers don't acknowledge my existence much less my opinions.
|
|
