Xref: utzoo news.software.b:1523 news.software.nntp:60
Path: utzoo!utgpu!attcan!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!cadre!pitt!cisunx!cmf
From: cmf@cisunx.UUCP (Carl M. Fongheiser)
Newsgroups: news.software.b,news.software.nntp
Subject: Re: Reading news: NNTP v.s. NFS for access to the database
Message-ID: <11498@cisunx.UUCP>
Date: 3 Aug 88 19:23:27 GMT
References: <16342@tut.cis.ohio-state.edu> <4246@pasteur.Berkeley.Edu> <19153@tut.cis.ohio-state.edu>
Reply-To: cmf@unix.cis.pittsburgh.edu (Carl M. Fongheiser)
Organization: Univ. of Pittsburgh, Comp & Info Sys
Lines: 31

In article <19153@tut.cis.ohio-state.edu> bob@kazoo.cis.ohio-state.edu (Bob Sutterfield) writes:
>The biggest delay in rrn is when following a subject thread with ^N,
>or when building an unread-articles subject list with =.  Kill files
>seem to take forever, too.  This implies to me that you win with local
>rn (or with rn reading from an NFS-mounted filesystem) because you
>needn't ship the whole article across the wire just to peek at the
>headers.

Rrn *is* pretty stupid about such things.  If you're using one of the newer
ones, the '=' functionality isn't too bad, because then rrn will use the
XHDR extension.  ^N and friends could use the same trick, but they don't,
currently.  Kill files could be speeded up enormously if rrn would use
HEAD instead of ARTICLE to do the scanning.

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.
For that matter, it never takes advantage of the hints the NNTP server provides.
The GROUP command always returns the range of articles in a newsgroup, but
rrn depends on using a local (and possibly inaccurate) copy of the active file.

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.

				Carl Fongheiser
				University of Pittsburgh
				Computing & Information Systems
				...!pitt!cisunx!cmf
				cmf@unix.cis.pittsburgh.edu
				cmf@pittvms.BITNET