Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.news.b
Subject: Re: expire takes 73 minutes of cpu?!?!?
Message-ID: <4658@utzoo.UUCP>
Date: Mon, 19-Nov-84 18:00:32 EST
Article-I.D.: utzoo.4658
Posted: Mon Nov 19 18:00:32 1984
Date-Received: Mon, 19-Nov-84 18:00:32 EST
References: <1828@nsc.UUCP> <>, <1859@nsc.UUCP>
Organization: U of Toronto Zoology
Lines: 22

> >The obvious solution is to put the expiration date in the history file.
> 
> Unfortunately, it isn't quite so obvious. Expire has the '-e' flag that 
> changes the time to expire, plus the '-i' and '-I' flags that cause it to
> ignore 'Expires:' header lines. Use of any of these flags make generating
> expiration dates for the history file at reception time impossible. ...

It's still dead simple.  If the file came in with no explicit expiry date,
you simply record it as such in the history file.  (The way we do it is
to give the expiry date as "-" in this case.)  The history file is
already recording the arrival date, which (around here, at least) is the
other date that expire needs to look at.  Expire can make its decisions
exactly the same way it has in the past, but rather more quickly.

> If we DO change the history file format, what does this break? Anyone out
> there have any ideas?

It broke practically nothing here; I had to make very small adjustments
in one or two places.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry