Re: Nntp inefficiencies

[Paul Franklin <paul@cs.washington.edu>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]

>>>>> Kurt Swanson writes:

 > Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

 >> and when `g'-ing, to get the real number of unread
 >> articles in the group buffer.  The latter would probably take far too
 >> long, though, to be of any use.

 > No, this wouldn't be good, but we could get the desired information
 > much easier - enter the group (in nntp parlance).  It seems that the
 > entire universe in the gnus-plane is based upon the response to the
 > nntp command, "LIST ACTIVE «group-name»".  The active files for mail
 > groups and for the cache have the same format as the output from this
 > command:
 >   "«group-name» «highest-article-number» «lowest-article-number» y"
 > I have no idea what purpose the "y" is for, well maybe it's a
 > moderation flag? If one instead entered the group via:
 >   "GROUP «group-name»",
 > the response one gets is
 >   "211 «number-available» «lowest» «highest» «group-name»"

 > This is of course an O(1) operation, instead of the O(n) LISTGROUP,
 > when one is only interested in the number of available articles.

 > It would be nice if the entire gnus-plane used the GROUPS sort of
 > format - including the number of articles in the range.  This is
 > especially useful in mail groups and caches.  For instance, I keep a
 > special nnml group for all email which needs my attention to which I
 > have not responded.  Many times my attention can't be given for
 > months, and despite my usually never having more than 20-30 such
 > messages, the difference between max & min article number is often >
 > 200.  Thus I am often queried if I really want to bring up 231 (or
 > whatever) messages, when there are in reality only 17...

Yup; a lot of people have requested something like this.  And Lars
keeps saying that it's too hard to compute, in a variety of
circumstances.  But I think there's another way...

By caching a tiny bit of extra information, Gnus can make a much
better guess at an article count.  Suppose that whenever you exit a
group, it records the actual article count, and the «highest»
article number according to the active file.  Call these cached
values CCount and CHi.

CCount now tells us how many articles are actually below CHi.

Then we do a "g".  We now have new values Lo and Hi.  We can now
calculate an article count:
	CHi = max(CHi, Lo-1)
	count = CCount + (Hi - CHi)
This article count is still not exact, but it's a lot closer.

For nntp groups, this avoids entering the group.  (Is this always
fast enough that it's a non-issue?)  But the real win is other
groups.  Lars hasn't wanted Gnus to go through the unread article
ranges on the fly and compute a real article count.  But since
articles should only disappear from mail groups while in a group or
while in a group or while running expiry, it should be pretty easy
to keep this data totally up to date.

I might have time the week after next to hack on this...

--Paul