Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!unmvax!uokmax!servalan!rmtodd
From: rmtodd@servalan.uucp (Richard Todd)
Newsgroups: news.software.b
Subject: Re: Expire by Date:
Message-ID: <1991Mar16.024826.3642@servalan.uucp>
Date: 16 Mar 91 02:48:26 GMT
References: <1991Mar14.012332.20774@massey.ac.nz> <1991Mar14.194554.12750@zoo.toronto.edu> <580@rufus.UUCP>
Organization: Ministry of Silly Walks
Lines: 43

kurt@rufus.almaden.ibm.com (Kurt Shoens) writes:

>What I would rather do is give expire two objectives:  get me back B
>blocks of free space and I free inodes.  Then, expire should
>essentially rank the articles that I currently have and delete the
>least precious (typically, the oldest, but you have to take into
>account the Expires:  header) until the objectives have been met.  If
>the news flow slows down because of, e.g., Spring Break, then I get to
>keep a little more.  If it picks up, I keep a little less.

>With this sort of control, I don't think that folks would be flipping
>between posting date and arrival date as the expiration criterion.

>Or does CNews expire already support what I'm suggesting?

Hmm.  I once implemented something sort-of along the lines you suggest,
back when I was trying to fit all of Unix plus a small newsfeed on the 80M
internal drive on my Mac (can you say "cramped", boys and girls?).  It took
a rather brute-force approach, simply having a bunch of progressively
tighter "explist" files which a modified version of C News's
$NEWSBIN/expire/doexpire would run through, invoking expire with each
explist file until a certain pre-set amount of free space was cleared up.
Like I said, brute force.  One nice thing about the system is that since
the explists are completely arbitrary, you can tailor the expiry behaviour
to some extent (i.e. make it expire news.groups to the bone before starting
in on comp.unix.lizards :-) I eventually had a shell script set up to
automatically generate all my explists from a single master file.  The 
scheme did a fairly good job of tracking variations in the newsflow,
adjusting the amount of expiration done as required.  (Learned some 
interesting things that way, too, like that newsflow drops substantially 
on the weekends--enough so that the "auto-adjusted" expire times always
increased by at least a day).  
  I've still got the code lying about, even though it doesn't see much 
cause to fiddle expire times ever since I got a bigger disk.  Let me know
if you're interested.
  For the record, I recall that someone else on the net (Chip Salzenberg,
maybe?) thought up the idea of progressive expires for adaptive handling
of expiration.  His scheme was somewhat more elaborate, in that it would
actually compute a new explist on each pass, instead of relying on explists
already created in advance.   I went for simple instead of elaborate...
--
Richard Todd	rmtodd@uokmax.ecn.uoknor.edu  rmtodd@chinet.chi.il.us
	rmtodd@servalan.uucp