I'd like to make some suggestions for the 2.0 per-list configuration
files. (and yes, I'm planning on implementing these changes, working
with Arnold de Leon). I think that these changes work with the 2.0
specifications. We haven't started thinking too much about
implementation, just what we want to do.
Let me know what you think, both from a design standpoint, and
an implementation standpoint. Once we decide what we are trying
to do, we'll get to details like how to pass function parameters :-)
For each command, I'd like to have a command_policy variable
(which_policy, who_policy, subscribe_policy, etc). This can contain
the current policy definitions of private, open, closed, and whatever
else is appropriate for a given command. It could also be set to
something special, to flag the name of a perl function to be called.
Since we need to be able to call the function either before or after
the command is executed, the "special" keyword could tell it to
look for variables defining the names of perl functions to be called.
command_policy = special
command_policy_pre = run_me_before
command_policy_post = run_me_after
where "run_me_before" and "run_me_after" are perl functions.
Or it could just always look for the pre and post functions
and "special" would not need be needed.
The additional functions could either be found in files named after
the functions or another variable could specify the location.
This is getting to be a lot of configuration on a per-list basis. In
fact, I think that there is already too much that has to be done for
each list as of 1.90. The other thing I'd like to add is an include
mechanism, so that I can somewhere define a configuration file, and
then instead of listing those same values for every similar list, I
can include that listtype:
list_type = sharedlist
where sharedlist is a majordomo configuration file in
/usr/local/majordomo/listtypes or something similar. We could also provide
configuration files for some of the most common types of lists, so that
someone that wanted an open list with no archiving and no digest could
simply have a config file that said
list_type = open
I think that we need to be able to specify multiple include files, so
that (for instance) one could be used to specify archiving, and one
digest, and one list policy. Anything listed after an include should
override anything in that file.
laura de leon
deleon@hpl.hp.com
(with arnold de leon
arnold@synopsys.com)
Follow-Ups:
|
|
