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
This is an ambiguous comment: does "changing the emp[l]oyee database" mean
changing its structure and programming, or updating its contents via adds
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 <email@example.com> <URL:http://www.panix.com/~tneff/>