From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/18313 Path: main.gmane.org!not-for-mail From: Paul Franklin Newsgroups: gmane.emacs.gnus.general Subject: Re: Nntp inefficiencies Date: 29 Oct 1998 11:43:38 -0800 Sender: owner-ding@hpc.uh.edu Message-ID: References: <6f67d62e2s.fsf@dna.lth.se> <6fpvbbo9ed.fsf@dna.lth.se> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035156858 5478 80.91.224.250 (20 Oct 2002 23:34:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:34:18 +0000 (UTC) Return-Path: Original-Received: from fisher.math.uh.edu (fisher.math.uh.edu [129.7.128.35]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id OAA16246 for ; Thu, 29 Oct 1998 14:46:21 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by fisher.math.uh.edu (8.9.1/8.9.1) with ESMTP id NAB08432; Thu, 29 Oct 1998 13:44:21 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 29 Oct 1998 13:44:09 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id NAA28525 for ; Thu, 29 Oct 1998 13:43:57 -0600 (CST) Original-Received: from sequoia.cs.washington.edu (sequoia.cs.washington.edu [128.95.4.203]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id OAA16113 for ; Thu, 29 Oct 1998 14:43:43 -0500 (EST) Original-Received: (paul@localhost) by sequoia.cs.washington.edu (8.8.8+CS/7.2ws+) id LAA31394; Thu, 29 Oct 1998 11:43:38 -0800 Original-To: ding@gnus.org In-Reply-To: Kurt Swanson's message of "Thu, 29 Oct 1998 12:13:31 GMT" Original-Lines: 63 X-Mailer: Gnus v5.6.39/XEmacs 20.4 - "Emerald" Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:18313 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:18313 >>>>> Kurt Swanson writes: > Lars Magne Ingebrigtsen 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