Jason L Tibbitts III said:
> >>>>> "MTA" == Mordechai T Abzug <morty@sled.gsfc.nasa.gov> writes:
>
> MTA> The second problem is relatively trivial to solve, but the first is
> MTA> much more tricky. I was thinking hacking around with 1.94.4, but
> MTA> before i do: is some facility to handle this sort of issue going to
> MTA> appear in 2.0?
>
> Well, exactly how do you want to handle it? If you're content to send a
> nice message back to the users telling them that they can't unzubscribe
> from the list directly
[snip]
I was hoping to let users do unzubscribes, so that wouldn't be what i was
looking for. :( What would work would be some mechanism that would treat a
list as four separate files: (1) the current people subscribed to the list;
(2) the current database output; (3) the current list of people who are
zubscribed to the list, but *not* in the database; and (4) the current list
of people who are in the database, but unzubscribed. It should not be too
difficult to rebuild the first list from the remaining three as needed, but
modifying majordomo to actually use all these lists is perhaps a bit more
problematic.
> If you want something stranger, you'll have to spell it out. It would
> probably be difficult to have Majordomo feed directly from your database,
> as it expects to be able to store information in that database, but I could
> be persuaded to make a "no-modify" class of lists.
As above, i'm definitely looking for something stranger. :)
> BTW, in any case you won't be able to just scp your lists in any more,
> because the list file is no longer simple. You can, however, just call the
> shell interface to wipe your list and incorporate a new address list
> quickly.
Cool.
--
Mordechai Abzug Raytheon STX morty@sled.gsfc.nasa.gov
Unix Administrator NASA Goddard Space Flight Center Code 242
CNE 301.286.8787
Follow-Ups:
References:
|
|
