Speeding tradspool expiry

[Russ Allbery]

Katsuhiro Kondou <kondou at nec.co.jp> writes:
> Russ Allbery <rra at stanford.edu> wrote;

> } I want to use a large tradspool spool for my new reader server, so I'm
> } trying to tackle the slow expiration speed problem that was introduced
> } when we went to the storage API.

> I think this should be fixed also for many other news admins.

Okay, I went with my original idea, which is really a hack but it was fast
and I need to get the new server up this week.  I'll start committing the
pieces of it tonight, probably, now that I've finally got it tested and
working.  Ran into a few other interesting bits to fix too while I was at
it.

> } Does this sound okay to people, and does anyone have any other ideas?

> Storage api brings us not only general method to access articles
> but also thick wall when accessing thru tradspool.

Yeah.  :/  It's really annoying.  It's made me wonder if we should
consider trying to store the crossposting information in the storage
mechanisms somehow.  But that would require a format change of all of
them, plus probably a good way of assigning numbers to groups so that the
information is somewhat compact (in other words, tradspool.map for all of
INN), and that's a huge project and not something I really want to tackle
after a few other things have been taken care of.

The whole expire system really needs to be reworked, though; I keep
getting confused when I try to work on it.  I think merging expire and
expireover may be a good idea in the long run, but I haven't really
thought about it much yet.  When I get a chance, I'll try to think through
the architecture and see if I can come up with a structure that would make
it simpler.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>