History File over 2GB

[greg andruk]

bill davidsen wrote:

> Off the top of my head:
>  - delete art: cancel, rollover, expire
>      delete the pointer, and the article itself in art-per-file
>      leaves the msg-id remembered

The rollover stuff might be better noticed and flagged by readers than innd.

>  - delete MID from history: expire
>      also should delete art?

I can read this as meaning maybe three different things.  MAybe an example?

>  - checkhistory: incoming arts
>      just return seen/unseen (wwould this be faster than graphistory?)

Definitely faster if you're only checking a small number of IDs per 
process.  dbz can already do this, it just needs to be exposed, really.

>  - grephistory: head, article, feed
>      MID->SM_token (or fail)

sm and grephistory could stand some small tweaks.  What I'd like to see:
- grephistory gets an "interactive" mode kind of like what sm with no 
command flags now.
- sm's interactive mode prepends an rnews header (easy) or spits out a 
dot-stuffed-and-termed article (busier and probably less useful) to make 
it more suitable for running through a pipe.

I kind of like that the two aren't currently trying to do each other's 
job, though.  Any more elaborate, and you might as well just fire up an 
nnrpd.

> and it would probably be better to include a flag to delete overview for
> an article as well, to avoid mismatches between data and information.
> Clearly this would be a problem for non-database overview, perhaps a
> queue of deletes to process? Not easy to do fast, but expire is
> something I'd love to avoid.

tradinidexed in particular wants careful handling, since that and 
tradspool are supposed to be there to support spool-based readers.  The 
cheap and easy approach of poking an invalidation string into the middle 
of .overview kind of loses there =(

> COmments?

None at this time, um, never mind.