#
# In message <9309021823.AA08022@mycroft.GreatCircle.COM>, Brent Chapman writes:
# > There's another reason for adding "set LIST PASSWORD KEY VALUE",
# > "show LIST PASSWORD [KEY ...]" commands rather than simply accepting a
# > per-list config file.
#
# Gosh darnit Brent, I just finished handling (about 30 seconds ago) the
# code for newconfig/config being treated as newinfo/info (I forgot the
# locking code last night 8-(), and now you want set/show key value too
# 8-)!!
Yeah, well...
# > If you use a per-list config file, and just send it back to somebody
# > when they ask what the current configuration is, they can't see what
# > all the default settings are; they'll only see what's in the config
# > file.
#
# Hmm, good point sort of. I claim that nothing should be defaulted, but
# that's just me.
I think you've gotta have defaults... Majordomo is just too damn
complicated otherwise. I think it makes more sense to have the
defaults be site-specific, though, rather than hard-coded into Majordomo.
# > On the other hand, if Majordomo knows what all the possible config
# > variables are (and it would have to, with a "set/show" syntax), then
# > it can tell you what all the settings are (even the ones that are
# > defaulted, either in the code or in the per-site Majordomo.cf file).
#
# I have an associative array that is used to determine if a key is
# known. The values for the array elements are the default values iff no
# listname.* files exist, and if no flags were given to resend. It's
# just that the default values depend on things, e.g. if a list.closed
# file exists, then the default value for closed will be yes, not no.
# Also, for some things like the -I flag for resend, the default value
# is whatever is in the aliases line, so determining defaults, while
# keeping backward compatibility is tricky. If none of these thiongs are
# in effect, then the defaults can be documented right in the config file.
I'm real tempted to deal with "backwards compatibility" by writing a
conversion script you'd run just once that examines the set of
<list>.<flag> files, creates an appropriate <list>.config file, and
deletes all the old <list>.<flag> files.
# So do you thing the defaults file should be a seperate config file, or
# should it be an array that can be set in the majordomo code itself? I
# also make the claim that anybody who screws around with the default
# file is a fool since he will have to explain to all of the people
# running lists why their lists just went from open to closed,
# non-private to private etc. I really can't see where a master switch
# like this helps (I actually believe it hurts) when there is more than
# one person running the lists.
Maybe the defaults file should just be a template used when a new list
is created, or if a <list>.config file isn't created when the list is.
Some people may want the behavior you describe above; I don't want to
make their choices for them.
-Brent
--
Brent Chapman Great Circle Associates
Brent@GreatCircle.COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
Follow-Ups:
|
|
