Path: utzoo!utstat!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!mejac!orchard.la.locus.com!prodnet.la.locus.com!ITcorp.com
From: geoff@ITcorp.com (Geoff Kuenning)
Newsgroups: news.software.b
Subject: Re: Passing on unwanted groups
Message-ID: <15112@.la.locus.com>
Date: 10 Aug 90 22:17:31 GMT
References: <1990Aug7.143458.1770@sci.ccny.cuny.edu> <747@sci34hub.UUCP> <1990Aug9.152342.29200@zoo.toronto.edu> <1990Aug9.205409.28967@sci.ccny.cuny.edu>
Sender: news@locus.com
Reply-To: geoff@ITcorp.com (Geoff Kuenning)
Organization: Locus Computing Corporation, Inglewood, CA
Lines: 25

In article <1990Aug9.205409.28967@sci.ccny.cuny.edu> jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes:

> binaries groups (the groups with the smallest demand here).  It would
> appear to be (diskwise) more convenient to receive the article just
> long enough to batch/compress it, and then kill our copy of it.
> 
> What it looks like (through email and followups) is that I *do* have
> to have a local copy, at least until the batcher gets run, and the
> article is packed up for transmission.

The above paragraphs suggest another answer:  arrange to have the unwanted
articles batched separately, perhaps in "togo.nothere" or under a
different directory.  Then run a modified sendbatch that rm's the
articles immediately after batching them up.  You might even run that
batcher more often so that the directories stay clean.  A little more
cleverness in the sendbatch.nothere script will even handle multiple
feeds nicely.

The only problem I can see with this scheme is that expire, upon seeing
that an article has disappeared, might not keep the message-ID around for
duplicate-prevention purposes.  My guess is that this is similar to
cancelled messages, and thus not a problem, but I haven't investigated
personally.  Do Henry or Geoff care to comment?

	Geoff Kuenning	geoff@la.locus.com	geoff@ITcorp.com