🚀 go-pugleaf

In article <839195995snx@holly.demon.co.uk>,
Mark Rogers  <mcr@holly.demon.co.uk> wrote:
>
>5) Following on from (4), I understand that KA9Q stores the list of mail 
>recipients in memory rather than reading them on-demand from the .WRK 
>file, resulting in an inability to cope with mail to more than a certain 
>number of recipients at once (presumably memory limited). If KA9Q didn't 
>need to read the full list for display purposes (see (4)) there's 
>presumably no reason why the bulk of the .WRK file couldn't be read when 
>needed, and the interim memory saved? 

For an individual message, this behaviour is required by, I think,
RFC 1123, one of the internet STD documents; it allows copies to the same
host to be coalesced (modern Unix mailers go further, and coalesce for the
same MX set).  I think it may do the same within batches to allow it
avoid reconnecting to the same site multiple times.

>6) Option to limit history file size, preferably on loading. That is, as 
>the file is loaded, everything over (say) 1000 lines results in the first 
>stored history article being dropped from the list before the new is 
>added. New articles are then added to the list on reciept without tailing 
>the history file further, and the new (shorter) list written to disk on 
>completion. I'm not sure how feasible that would be; perhaps best left to 
>external utilities (I do this already, and KA9Q generally behaves better 
>for it, IME).

This is best done by an external utility, as KA9Q simply extends this
file.  Remember, also, that anyone with more than 500 bytes of news
groups cannot simply retain the last few minutes of old messages, but
must keep all the last run, except the first batch, if nothing ever
fails, and considerably more if runs ever abort.  The reading of the
history file would have to be done backwards to allow KA9Q itself to cut
off early, as it can't undo hash table entries, once created.

Note that history file entries are never stored, only bits in a fixed
size hash table.  The performance hit for large history files results
from a higher proportion of false positives in the hash table.  KA9Q
looks to see if two bits are set in a hash table (for small history
files, using two bits decreases the risk of false positives by a power
of 2).  If it gets a hit in the hash table, it reads round the history
file until it catches up with itself, or finds the message ID.  True
positives normally result in a short forward search; false positives, in
a complete scan.

>Obviously memory requirements are an important consideration, and 
>conversion to protected mode is really the only way around that. In fact, 
>the only way for KA9Q to survive for much longer will be with a PM 
>version so that new features can be added to it (like a lynx viewer, 
>etc). 

I think there is limited future in this, as one can run a Unix clone in
similar hardware (certainly in 4M 386SX) to that needed for a 
protected mode KA9Q.
-- 
David Woolley, London, England          david@djwhome.demon.co.uk