Path: utzoo!mnetor!tmsoft!mason
From: mason@tmsoft.uucp (Dave Mason)
Newsgroups: news.software.b
Subject: Re: Review of NN, a Usenet news reader
Message-ID: <1989Aug7.172232.24974@tmsoft.uucp>
Date: 7 Aug 89 17:22:32 GMT
References: <1836@papaya.bbn.com> <1150@sequent.cs.qmc.ac.uk> <1050@unocss.UUCP> <402@laas.laas.fr> <2794@mace.cc.purdue.edu> <339@capmkt.COM> <377@texas.dk>
Reply-To: mason@tmsoft.UUCP (Dave Mason)
Followup-To: news.software.b
Organization: TM Software Associates, Toronto
Lines: 51

In article <377@texas.dk> kim@texas.dk writes:
>To turn the ball back to all the people who think .newsrc is adequate
>(I know it is standard, so don't tell me that :-):
>
>Since nn automatically splits all digests into separate articles and
>transparently handles these undigested articles as normal articles,
>how do you suggest to use .newsrc to mark *part of a digest* as unread??

Code digest elements that have been read with a octal bit vector as a
fractional part on the article number.  So that if you had read
articles 1-45, 50 parts 1,2,5,6,9 (of 20) and 52-59 the .newsrc line
would look like:
	random.group: 1-45,50.631,52-59

This should work fine, as digests rarely have more than 5-10 articles
which would only add up to 5 characters to the .newsrc line.

With a one line change to arbitron, it would work. There is a test for
the range of the current article number that says (around line 157):
	if ((grpfirst != grplast) && (lastread >= grpfirst) && (lastread <= grplast)) {
this must be changed to:
	if ((grpfirst != grplast) && (lastread >= grpfirst) && (lastread < grplast+1)) {
I think it's quite reasonable for people to apply a trivial, compatible
patch to arbitron.

Unfortunately I don't know how rn would respond to that 50.631.  At
worst it will break or ignore the line.  At best it will keep the
information as it is on that article.  Most likely it will truncate it,
and consider all of article 50 as read.  This is somewhat important to
people who use different readers from different places on the same
.newsrc file and for people who want to try nn without having their rn
.newsrc junked.

>With the next release of nn (6.4), the nn counterpart to .newsrc will
>be able to do this (this information is kept in files separate from
>nn's rc file).
I'm not convinced that keeping separate files is the right approach.

>And with all the fuzz about .newsrc, I probably also include a more
>complete .newsrc support in release 6.4.  But no promises....
>
>-- 
>Kim F. Storm        storm@texas.dk        Tel +45 429 174 00
>Texas Instruments, Marielundvej 46E, DK-2730 Herlev, Denmark
>	  No news is good news, but nn is better!

Sounds like you've done some interesting things here, but I think
keeping a somewhat compatible .newsrc is one of the things you should
do, even if it doesn't produce quite as good a program in some
theoretical sense.
	../Dave