Newsgroups: news.software.b
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: expire
Message-ID: <1991Jun24.200612.16002@zoo.toronto.edu>
Date: Mon, 24 Jun 1991 20:06:12 GMT
References: <4313@anasaz.UUCP>
Organization: U of Toronto Zoology

In article <4313@anasaz.UUCP> rusty@anasaz.UUCP (Rusty Carruth) writes:
>When I run expire, I am usually wanting to free up some given amount
>of disk space (for incoming news to land in, for example).  I rarely
>am thinking of limiting the length of time articles hang around in
>a newsgroup ...

We actually have two different user communities here, with the distinction
a function of how tight your disk space is.  Those of us with reasonably
ample resources (for the moment!) do tend to think about hang-around time.

>  lump newsgroups into one of 3 categories: junk, good, archive (archive
>      is not currently being done)
>  set "high" and "low" limits for each newsgroup (see below for their use)
>  set "rate" values for each newsgroup (also see below)
> ...
>Another person here has an idea based upon priorities and such, but it seemed
>even harder to implement than my hare-brained idea :-)

The main reason why we didn't attempt something like a space-based expire
in C News was the problem of defining what the policy should be.  The more
I tried to write a description, the more complex it got, and the less
obvious it was that people could understand it and that it would meet
their needs.  What you've defined is a plausible approach if your groups
can be split into those three categories easily.

>Reading the doc for expire, it looks like I could add another field to the
>middle field of the history line which contains the SIZE of the file (thus
>saving me from having to scan the entire directory structure to calculate
>file sizes).  Would there be any massive problems with doing this?

I thought very seriously about doing exactly this, in fact, and the only
reason it wasn't done was that in the end I didn't have a use for it.  I
think nothing should mind; nothing in C News depends on having exactly two
subfields, although it's possible that other stuff (NNTP?) does.  Putting
a size in as a third subfield is a reasonable idea, although please do it
in bytes -- the concept of "block" is not portable.

>Also, I take it that a '-' in the second subfield means that the
>article has been expired?

No, no.  Please read the documentation!  It means that no explicit expiry
date was supplied.

>Would the "powers-that-be" be interested in including my version of
>"param_expire" (or whatever in the world it turns out to be called)
>in future Cnews's (as an optional method for expiration)? ...

It's not out of the question, but I'd like to see more attention to a
sophisticated policy mechanism.  As you've specified it so far, it could
be done without too much trouble using iterative running of the existing
expire with tighter (possibly mechanically generated) explists.  Not as
quick as a single pass, but probably acceptably fast for most sites, and
it would be much simpler to set up.
-- 
"We're thinking about upgrading from    | Henry Spencer @ U of Toronto Zoology
SunOS 4.1.1 to SunOS 3.5."              |  henry@zoo.toronto.edu  utzoo!henry