Has everyone gotten 1.5n up?  Are we ready to start thinking about where
to go next?  Here are some items I wish for:
 
 
 - An exit to be invoked with at every ADD/SUBSCRIBE.  Actually
   there probably should be two exits for ADD/SUBSCRIBE.  The first
   should be before the user has been added to the listname LIST file,
   but after all the other checks, such as service area, etc.  This exit
   would allow a finer rejection method.  The second exit(the one I want
   the most) would be invoked after the user was added to the listname LIST.
   I have modifications into LSVSUBSC and LSVADD now to handle this.  It allows
   me to implement a keyword I call Auto-AFD.  Whenever I add a user to this
   list, they also automatically get an AFD to a particular file/package.
   There can be multiple AFDs.  I haven't implemented FUI, but it is trivial.
 
 - Similar exits to DELETE and UNSUBSCRIBE.
 
 - Make the PEERS NAMES a searchable database.
 
 - Make (at least parts) of PEERS NAMES dynamically maintained.  We have
   seen with the Network-wide list of lists that dynamic reconfiguring of
   the listserv netowrk is possible, and even feasible.  Allow me to maintain
   a file(eg LOCAL NAMES) which would have my entry for PEERS NAMES.  I
   could change things in it, and at some remote time, it would distribute
   an update to the other servers.  Somethings would not be possible to
   be trusted to the postmaster, but some items definitely could be.
   Fields such as :emergency are such canditates. :version is not, and
   should be dynamic.  :lists is obsolete.
 
 - A reduction in the returned output from a network-wide delete.  There
   are too many messages returned.
 
 - Others that I haven't thought of.
 
Harry
 
PS None of the above should be taken as thinking that I don't like 1.5n.
I do.  But where do we go from here?
 
Is it my imagination, or does mail arriving for a list that is held go
out in the reverse order(LIFO) when it is freed?