Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!think.com!snorkelwacker.mit.edu!ira.uka.de!smurf!urlichs From: urlichs@smurf.sub.org (Matthias Urlichs) Newsgroups: news.software.b Subject: Re: Up to the minute dial-up newsfeed Message-ID: Date: 6 Mar 91 20:08:02 GMT References: <1991Feb26.024320.24820@looking.on.ca> <1366@bacchus.esa.oz.au> <1991Mar02.071733.23588@looking.on.ca> Organization: University of Karlsruhe, FRG Lines: 22 In news.software.b, article <1991Mar02.071733.23588@looking.on.ca>, brad@looking.on.ca (Brad Templeton) writes: < There are several reasons for wanting an up to the minute feed. [.. three reasons deleted ..] Fourthly, not batching means that cancelled articles don't get batched and transmitted. Good idea if you ask me. One solution would be a specialized user-level "NFS" server which could offer a file for batching. The advertised size for that file won't matter because uucico just looks for EOF when using the g or f protocol. Removal of the file would indicate successful transfer, and if the server has more it could just queue another batch. Depending on the UUCP used you may get some superfluous master<->slave turnarounds, but that can be worked around by estimating how many batch jobs are needed and creating them at startup. This might not work with all machines (you'll need at least NFS and a reasonably intelligent file system for concurrency), but it should work without risking data loss. -- Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\ Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/