At 02:27 PM 2/3/98 , Mordechai T. Abzug wrote:
>I sent this yesterday afternoon, but didn't munge it enough. Critical
>thing to note: changing the empoyee database is really not an option (for
>me, anyway).
This is an ambiguous comment: does "changing the emp[l]oyee database" mean
changing its structure and programming, or updating its contents via adds
and removes?
If you cannot update the contents of the employee database in any way, even
periodically, as a result of adds and drops commanded directly to
majordomo, then you are doomed to a monotonically increasing list of
excludes and supplemental names to be handled after the database-supplied
list of addresses. Frankly this would be a stupid thing and I would lobby
to change it.
If you _can_ update the contents of the employee database, or the portion
of it that affects list membership, then I will reiterate what I posted
earlier today (no mention of which was made in Mordechai's 2pm message):
You can do this without hacking Majordomo at all, simply by changing the
_owner alias to pipe to a standalone script that looks for adds and drops
and reformats them into database update requests which are sent to the
appropriate server. At most a five line Perl program.
As for the database->majordomo data path, remember that the members list is
a simple textfile, easily generated on the database side. You don't need
to send actual commands, just copy down the new list as a file.
Having sent this twice, I'm moving on - I know I could do it in an hour but
is not my yob. Good luck.
--
Tom Neff <tneff@panix.com> <URL:http://www.panix.com/~tneff/>
Follow-Ups:
References:
|
|
