Xref: utzoo news.software.b:1524 news.software.nntp:61
Path: utzoo!utgpu!attcan!uunet!husc6!rutgers!ucsd!ucbvax!agate!garnet!weemba
From: weemba@garnet.berkeley.edu (Obnoxious Math Grad Student)
Newsgroups: news.software.b,news.software.nntp
Subject: Re: Reading news: NNTP v.s. NFS for access to the database
Message-ID: <12962@agate.BERKELEY.EDU>
Date: 4 Aug 88 11:49:22 GMT
References: <16342@tut.cis.ohio-state.edu> <4246@pasteur.Berkeley.Edu> <19153@tut.cis.ohio-state.edu> <11498@cisunx.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: weemba@garnet.berkeley.edu (Obnoxious Math Grad Student)
Followup-To: news.software.b
Organization: Brahms Gang Posting Central
Lines: 38
In-reply-to: cmf@cisunx.UUCP (Carl M. Fongheiser)

In article <11498@cisunx.UUCP>, cmf@cisunx (Carl M. Fongheiser) writes:
>Rrn's biggest problem (in my opinion) is that it always scribbles down
>*everything* it got over the wire onto disk.  I don't see any reason
>why rrn needs to write the whole article onto disk to do kill file
>processing.

Having written a comprehensive remote newsreader, the primary reason
for this is quite obvious to me: it's so much easier.  Doing a split
head and body fetch was quite tricky to get exactly right--among other
pitfalls, I had to suppress spurious(?) select(2) errors.

There's also the rare possibility of a /blah blah/a:j.  Well, maybe not
so rare--have you bothered to read news.admin recently?

Gnews doesn't support whole article searches, so this never occurs in
my case.  Also, Gnews does KILL processing on the fly, not all at once
at the beginning.

I'm in the process of rewriting Gnews internals to march down the
newsgroup in the background, caching up header and body information
while you're reading an article.  This is tricky enough in rn--to
do so asynchronously over NNTP is much more so.

Personally, I'd appreciate if NNTP would allow explicit buffering.  Ie,
not only "body ###", but say a "bodybuffer ### 30" to grab 30 lines;
the return message would tell how many lines remained to get.  The
all-or-nothing can be quite silly at times.  Among other applications,
this would permit fast implementation of KILLs based on a string within
the first so many lines.

>In sum, the current rrn is an imperfect molding of a file-system based
>news reader onto the NNTP model.  Rrn really *could* shine, but it'll
>take some work.

That's what I'm trying to make Gnews do.  Now that the first draft of
the manual is out of the way, I can dig into the internals again.

ucbvax!garnet!weemba	Matthew P Wiener/Brahms Gang/Berkeley CA 94720