From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/18468 Path: main.gmane.org!not-for-mail From: Paul Franklin Newsgroups: gmane.emacs.gnus.general Subject: Re: Nntp inefficiencies Date: 09 Nov 1998 09:58:31 -0800 Sender: owner-ding@hpc.uh.edu Message-ID: References: <6f67d62e2s.fsf@dna.lth.se> <6fpvbbo9ed.fsf@dna.lth.se> <6fg1c3ef1i.fsf@dna.lth.se> <6fu30as9mo.fsf@dna.lth.se> <6fogqixnli.fsf@dna.lth.se> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035156987 6315 80.91.224.250 (20 Oct 2002 23:36:27 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:36:27 +0000 (UTC) Return-Path: Original-Received: from karazm.math.uh.edu (karazm.math.uh.edu [129.7.128.1]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id MAA03990 for ; Mon, 9 Nov 1998 12:59:46 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by karazm.math.uh.edu (8.9.1/8.9.1) with ESMTP id LAB20646; Mon, 9 Nov 1998 11:59:03 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Mon, 09 Nov 1998 11:58:53 -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 LAA26785 for ; Mon, 9 Nov 1998 11:58:42 -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 MAA03965 for ; Mon, 9 Nov 1998 12:58:37 -0500 (EST) Original-Received: (paul@localhost) by sequoia.cs.washington.edu (8.8.8+CS/7.2ws+) id JAA00551; Mon, 9 Nov 1998 09:58:31 -0800 Original-To: ding@gnus.org In-Reply-To: Lars Magne Ingebrigtsen's message of "Sun, 08 Nov 1998 16:05:30 GMT" Original-Lines: 31 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:18468 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:18468 >>>>> Lars Magne Ingebrigtsen writes: > Kurt Swanson writes: >> It's not the size but the relation between them. Take a look again. >> The simple idea is that Gnus should never report more than the total >> number of server-available articles as unread. > And in the case I outlined, what should Gnus do? > This is not a rhetorical question. > In the special case you described, getting the number right is > trivial, but it's a fairly unusual situation. Just so everyone's clear, Kurt and I are looking at slightly different situations. I'm looking at the mail backends where Gnus has complete control over what's going on. For these backends, it should be trivial to get the number exactly right in all cases, and I think it is. But Gnus overestimates in ways which result in large errors with certain usage habits, as has been noted. As an extra bonus, it'll help Kurt's scenario somewhat. :) Lars, if I get this working, do you want patches? (I think this involves adding a group parameter, since I need to remember two extra per-group integers. Is there a better way?) --Paul