At 02:45 PM 1/19/98 -0600, Jason L Tibbitts III wrote:
>>>>>> "DW" == Dave Wolfe <dwolfe@risc.sps.mot.com> writes:
>
>DW> [ Bill Houle writes: ]
>>> The latter would support three levels of admin (owner, approver,
>>> moderator) and still default to the owner when not used.
>
>DW> Works for me.
>
>I should say that in the extended scheme I'm playing with in the
>development versions (where you can send approval stuff from any command to
>as many different addresses as you want to) this arrangement seems quite
>confusing. -approval is an alias, but moderator is a config variable?
>I've never been able to figure out how it's supposed to work, much less
>understand how we expect anyone else to.
>
>My plans for 2.0 is to ignore -approval altogether and to support moderator
>in a backwards-compatible manner (send post approvals there, everything
>else to owner unless directed otherwise by new variables). I don't want to
>rely on aliases for something like that.
In the 1.9x code, Majordomo has 3 "subsystems" identified in the config
file: majordomo, resend, and digest. Locally, we have added 2 others:
archive (for archival-related variables) and "address" for aliasing &
addressing purposes. Under this scheme, "archive_dir" should really be
labelled as "archive", while "moderator" is in the "address" category.
Anyway...we use this "address" class as an abstract layer to manage the
consistent application of aliases. $list-owner will always exist as an
alias, but what it gets set to depends on $config{owner}. This provides
consistency to the user (who always knows that $list-owner will exist),
while allowing flexibility for the list maintainer to reassign the
ownership as needed without requiring sysadmin/root access.
I can understand the confusion of alias vs keyword. IMHO, an alias should
only be an alias if an end-user needs to send mail to that address. If the
program itself needs to direct the mail, it should do so based on config
info it maintains rather than assuming an alias is present. By this logic,
the -owner and -request addresses should exist as aliases, but the
-approval should really just be in the config file. This would be trivial
to implement in 1.94, but it would involve a significant process change
when people try to upgrade. Is this something we would want to do?
As for 2.x, as long as (a) users still saw a consistent application of std
alias names, and (b) there were no hardcoded assumptions about where to
direct -approval and moderator type requests, then anything goes.
Preferably, one should be able to set the owner/moderator/etc addresses
from within the config file itself, which I believe you have already
provided for...
--bill
Follow-Ups:
References:
|
|
