Newsgroups: news.software.b
Path: utzoo!utgpu!watserv1!watmath!looking!brad
From: brad@looking.on.ca (Brad Templeton)
Subject: Up to the minute dial-up newsfeed
Organization: ClariNet Communications Corp.
Date: Tue, 26 Feb 91 02:43:20 GMT
Message-ID: <1991Feb26.024320.24820@looking.on.ca>

I have been thinking about setting up a dial-up up to the minute
newsfeed.   This would be a dial-up uucp feed which gives you all the
news that's come in to the second of your dialing in.

Now, of course the old one uux per article system did that, but now with
batching you only get news as of the last time you batched.

And with non-uucp dialups it would not be hard to arrange such a thing.  But
the idea system would work with uucp.

To do this, you of course need a command that will output the new news
batches.   Most batchers can be made to do this, and dynafeed (which is
what I will use) does it easily as well.

One idea is to use named pipes.  A named pipe would exist on the system, and
a daemon would be sitting waiting to open and write to that pipe.  It would
write a news batch to that pipe as soon as it unblocks.   One would then
arrange to uux an rnews of the named pipe file.  It does not matter if there
are multiple uux's queued up, as the latter ones will just do null transfers,
albeit wasting a bit of CPU.

Then the system calls in, and tries to copy over the 'pipe' file.  It gets
an up-to-the-minute news batch, probably all as one big batch.

This sounds ideal, but there's too much that can go wrong.  If the daemon
process isn't around writing to the pipe (should it die unexpectedly) the
uucp will hang waiting to open the named pipe.    And of course, it is hard
to figure what to do if the phone call aborts mid-file.   Do broken pipe
signals get sent on named pipes?  It does not seem so on my system but perhaps
I have not fully checked.   If they do, you can handle this one.

Sending all the news in one batch can be risky if there's a long blockage
that causes a mega-batch.  Batchers all have a batching limit and of course
you could arrange to uux the pipe several times.

----

Another idea is to change uucp's shell from uucico to a wrap-around program
that starts up the batcher in the background and then calls uucico.  Only
problem is that if uucico is too fast, it will quickly decide there is no
work to do and hang up before the first batch is queued by the batcher.  One
could delay the start of uucico until the first batch has definitely made
it, but this is not a great idea, and wastes phone time.

Of course, many solutions are possible with the source to uucico and
custom patches.   I don't have that, so am interested in more general
alternatives.

Any ideas?
-- 
Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473