wales@valeria.cs.ucla.edu (Rich Wales) (01/18/91)
In article <4528@lib.tmc.edu> rrn@lib.tmc.edu (Stan Barber) posted patch
#54 for RN 4.3 -- including a bug fix I reported having to do with RN's
tendency to toss unread articles in newsgroups where some unread arti-
cles had expired or been cancelled.
I'd like to discuss this bug in a bit more detail, and propose a minor
(and upward-compatible) change to the NNTP "NEXT" command which would
allow a much more efficient fix than the one I recommended (and which
Stan adopted in patch #54). I mentioned this idea in the bug report I
sent to Stan, but I'd like to present it for more general discussion in
case someone else sees a problem with it or has a better idea.
The reason for the bug in RN was apparently that the RN author thought
an NNTP "NEXT" command would find the first available article after the
set of unavailable articles previously sought via "ARTICLE" commands.
(That is, RN would ask for an article by number within the current news-
group; and, if said "ARTICLE" command failed because the article with
that number was gone, RN would use a "NEXT" command to move past that
point to the next article that was still around.)
However, the above approach didn't work, because the "ARTICLE" command
does not update the NNTP server's current article pointer if the article
requested does not exist. Thus, in the above scenario, the "NEXT" com-
mand would start with the last =successfully= read article -- which
could be anywhere in the newsgroup, and in particular could easily be
after the series of unavailable articles if the user were reading arti-
cles by topic (via ^N).
There doesn't seem to be any elegant solution to this problem under the
current NNTP protocol. The only thing to do (and the solution used in
patch #54) is to use a succession of "ARTICLE" commands (each with a
number that is one higher than the last) until an article is found that
=is= available. If a user is coming back to a newsgroup where a lot of
articles have expired since the last time he looked at it -- but he
wants to read whatever is there now instead of just "catching up" -- the
process of having RN ask for several dozen (or several hundred) expired
articles, one at a time, can be painful.
So, here's my proposal:
I propose that the NNTP "NEXT" command be modified to permit an optional
article number as an argument. An NNTP server, in this case, would tem-
porarily set the current article pointer to this value, then perform the
search for a next article from that point. If no "next article" were
found, the old value of the current article pointer would be restored,
so the command would end up having no effect on the server's state.
A "NEXT" command without an article number argument would continue to
work exactly as it does now.
Since a "NEXT" command cannot currently have an argument at all, adding
this extra feature to NNTP servers would not break any existing clients.
Further -- since NNTP currently rejects a "NEXT" command with an argu-
ment anyway (with a "501" error code) -- it would be easy for RN to
downgrade gracefully to the old behavior. RN could first use a "NEXT
nnnn" to find the next article after an unavailable article. If this
worked, great. If not, RN would revert to the "slow but sure" solution
in patch #54 (i.e., ask for articles one at a time until something was
found).
Comments on this proposal?
--
Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department
3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683
"I could be chasing an untamed ornithoid without cause."