According to Jason L Tibbitts III:
>
> GLOBAL:
> full addr
> strip addr
> password (probably encrypted somehow)
> bounce data (?)
> language
> warnings
> a list of lists the user is a member of
>
> PER LIST:
> full addr (for doing 'who' quickly)
> strip addr
> zub. class + args
> flags (need to be per list)
>
> Really, this is not difficult to split up but I want to split it once and
> leave it that way. I can see places where you might want a global default
> and a per-list override but I'd really, really like to try to get away
> without doing that.
Why not design it so even the global values have a key that could
be different per-list or not? Then if you end up being wrong you
just use a different identifier for the lists that turn out to be
different.
> Now, the global list doesn't even have to be Majordomo-maintained; it could
> be on an LDAP server somewhere assuming that the fields it needs can be
> created. The per-list stuff should be probably be internal, though.
>
> Ideas?
LDAP might be the best long-term choice, especially if you teach it to
automatically make the list addresses available and let sendmail use
it directly for the expansions, but I expect it to be several years
before many sites are prepared for that.
Right now you could use DBI with the base distribution set up for
DBD::CSV which uses a flat file storage instead of needing a backend
database. Places that outgrow that scheme or want access from
multiple machines could drop in their choice of server and DBD backends
without changing the base code.
Les Mikesell
les@mcs.com
Follow-Ups:
References:
|
|
