2.3exp: expire and tradspool

[Richard Michael Todd]

In message <19990820144746.A103810 at isc>you write:
>> And during expire last evening, expire.list contained 2787966 tokens, and
>> expire.log contained the exactly the same number of these lines:
>> 
>>     Class definition 0 is missing from control file, assuming zero expiratio
>n
>> 
>> Which would seem to indicate that expire treated all articles as if they
>> were in class 0.
>
>To follow-up on my own post, in storage/tradspool/tradspool.c lines 553-554 
>
>    token.type = TOKEN_TRADSPOOL;
>    token.class = 0; /* "class" is irrelevant for traditional spool */
>
>The question remains, shouldn't the real storage class get stored in the
>token so that storage class based expire can work?
>

You could hack something to keep the storage class around, but the problem is
that the storage class data would all go away the next time you did 
makehistory.  The fundamental problem is that, unlike the timehash, timecaf,
and CNFS spool types, where the storage class actually corresponds to a 
different region of disk where the articles are stored, all tradspool articles
end up in the same directory tree, so the notion of 'storage class' doesn't
really make sense here.

This does still leave you with the problem that you still would like
to specify the expire times on something finer than a whole-spool
basis.  I've got an idea of a way to bring back per-group-based expire
and doing so efficiently, which I may try to implement.  The trick
involves computing the expire time for each article at the time it is
stored, and encoding the expire time in the token.  This makes
expire's very simple, as it just has to unpack the token and compare
the stored expire time to the current time.  The catch is that changes
you make in expire.ctl won't take effect immediately, as the existing
articles on spool will still have the old expire times set.  I'd like to hear
opinions from people on this list on 

 a) whether this would be an acceptable limitation or
 b) whether they can think of a scheme for per-group expire that would be
decently  efficient, and *doesn't* have that limitation.