Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!intercon!amanda@intercon.uu.net
From: amanda@intercon.uu.net (Amanda Walker)
Newsgroups: news.software.b
Subject: Re: Review of NN, a Usenet news reader
Message-ID: <1332@intercon.UUCP>
Date: 2 Aug 89 17:02:46 GMT
References: <2794@mace.cc.purdue.edu> <404@laas.laas.fr> <2803@mace.cc.purdue.edu> <327@ncis.tis.llnl.gov> <2804@mace.cc.purdue.edu> <1989Aug2.024702.4879@nc386.uucp>
Sender: news@intercon.UUCP
Reply-To: amanda@intercon.uu.net (Amanda Walker)
Organization: InterCon Systems Corporation
Lines: 32

I'm afraid I'm going to have to side with Brandon here.  I have yet to see
any good reason for NN to use its own little read history format.  Reading
and writing a .newsrc can be made as fast as you want, and certainly as
fast as reading and writing any other kind of text file read history.

In fact, parsing a file that's just whitespace-delimited instead of
fixed-column oriented is probably *faster*, since you don't have to read
as much data off of the disk.

And if we're going to start talking about "generations" of newsreaders,
I'd claim something like this is the most reasonable way to split them up:

Generation 1:	news (anyone remember news A?) and readnews
		Basically, just send articles to the screen, piping
		through "more" if you're lucky

Generation 2:	vnews, rn, nn, notesfiles, etc.
		Use full-screen capabilities, limited "random access" to
		articles, rudimentary article preprocessing.

Generation 3:	Uses a very fast display (such as a workstation), complete
		random access to articles, complex article preprocessing,
		and so on.  The recent crop of GNU Emacs newsreaders are
		edging into this category.  Xrn would be in here if it
		actually did anything more than rn does.  This is where
		stuff is really starting to get interesting.

--
Amanda Walker
InterCon Systems Corporation
--
amanda@intercon.uu.net    |    ...!uunet!intercon!amanda