Natterings about history files

[Alex Kiernan]

Russ Allbery <rra at stanford.edu> writes:

> Alex Kiernan <alexk at demon.net> writes:
> 
> > OK, I'm a fairish chunk of the way there (at least for innd), but I'm
> > just trying to figure out if there's ever a need to return a "I've
> seen
> > that article but its expired" distinct from "I know nothing about that
> > article" from HISlookup - is there ever a need to retrieve the fact
> that
> > the history file knows posted/arrived information, but that its been
> > expired (other than via HIScheck)?
> 
> You mean, what HISlookup should return for articles that are still
> remembered as having been seen but which aren't stored on disk?  Hm.

Yup.

> Actually, no, I can't think of a reason... innd should use HIScheck to
> decide whether to accept an article, and nnrpd can't do anything with
> articles that aren't on disk any more.  The only program that I can
> think
> of that currently would want to know both pieces of information is
> grephistory, and it can easily enough call HIScheck followed by
> HISlookup.
> 

Looking at it again this morning (OVhisthasmsgid), it looks like it is
used during group based expiry - when an overview method determines
that the underlying storage manager is EXPENSIVESTAT, it attempts to
check whether there's a storage token still associated with the
message in the history file (fetch the offset from the dbz file,
break out & discard the times, check if we've a valid token left).

ISTM that if you just did a HIScheck you'd keep overviews for articles
for too long (which I guess isn't a disaster), alternatively we could
adjust HISlookup to return an expired flag (modifying the TOKEN to
include an expired flag sounds like a bad idea to me):

    enum status { NOTFOUND, FOUND, EXPIRED };
    enum status HISlookup(struct history *, const char *key, time_t *arrived,
                          time_t *posted, time_t *expires, TOKEN *token)

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC