I've found and  fixed two bugs in  LSVBITFD since yesterday -- I  knew I had
better be careful about it... :-)
 
  I have improved LSVXMAIL to implement  the type (1) headers we had discussed
(--> SET listname FULLhdr/SHORThdr) and  the "Mail-Via= DISTRIBUTE" keyword. I
have  completely  rewritten  the  mail-sending  routines  and  implemented  an
internal 'mail type' structure with  presently three types: short header, full
header, peer-format header.  This makes it very easy to  implement other types
of headers in  the future, eg type (2) headers  (--> SET listname TRANSPhdr?).
It also  made it  possible to  have mail sent  out to  peers before  the other
recipients (but don't get too excited  about that, peer-format = full header +
inter-server tags  so I seriously  doubt it  CAN reach its  destination before
short-header mail...)
 
  "Mail-Via= DISTRIBUTE" was not that easy to implement because of the various
header formats. I had to make provisions  to have one DISTRIBUTE job issue for
each type of header for which there  is at least one subscriber, and of course
it does not optimize execution time. Mail is always sent to peers directly for
better execution speed  -- anyway they're supposed to  be intelligently linked
and I don't expect  more than 2-3 peers per node. Valdis  will be testing this
feature on his UN*X-SRC list.
 
  I then  did some performance analysis  on LSVDIST. Amazingly, it  spent more
than 50%  of its time obtaining  the userid@nodes of all  the servers... there
are now 876 records in PEERS NAMES  and EXECIO has always been an outrageously
fast program  -- not nearly  as fast as NAMEFIND  but it could  almost compete
with it ;-)  LISTSERV will now build  a file called PEERS  NAMESUM whenever it
receives a new copy of PEERS NAMES, and  this info will be kept in storage and
subsequently retrieved by LSVDIST. Execution  time is now much more acceptable
:-)
 
  Eric