From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/40945 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: can back end keep track of *all* group info? Date: Sat, 22 Dec 2001 13:20:27 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035176422 3637 80.91.224.250 (21 Oct 2002 05:00:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 05:00:22 +0000 (UTC) Cc: ding@gnus.org Return-Path: Original-Received: (qmail 13718 invoked from network); 22 Dec 2001 12:23:54 -0000 Original-Received: from malifon.math.uh.edu (mail@129.7.128.13) by mastaler.com with SMTP; 22 Dec 2001 12:23:54 -0000 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16HlAj-00032q-00; Sat, 22 Dec 2001 06:22:37 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Sat, 22 Dec 2001 06:22:25 -0600 (CST) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id GAA27763 for ; Sat, 22 Dec 2001 06:22:13 -0600 (CST) Original-Received: (qmail 13614 invoked by alias); 22 Dec 2001 12:22:09 -0000 Original-Received: (qmail 13609 invoked from network); 22 Dec 2001 12:22:08 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by gnus.org with SMTP; 22 Dec 2001 12:22:08 -0000 Original-Received: from localhost.localdomain ([195.42.214.241]) (authenticated bits=0) by yxa.extundo.com (8.12.1/8.12.1) with ESMTP id fBMCMC3O001691; Sat, 22 Dec 2001 13:22:13 +0100 Original-To: Paul Grayson In-Reply-To: (Paul Grayson's message of "21 Dec 2001 23:50:57 -0600") Mail-Copies-To: nobody Original-Lines: 48 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:40945 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:40945 Paul Grayson writes: > My server keeps track of marks, and could report the number of > unread/flagged messages in each group for display in the *Group* > buffer. I don't want my server to count the total number of messages > in a group - that will take too long - and I want to avoid the nnimap > problem of always having the unread/flagged count out of sync with the > server. Which problem is this? Do you mean the one that unread/flagged count in Gnus is only an estimate? That applies to all backends, if it is noticable or not depends on the backend (and in nnimap's case, on the remote server). M-g on the group makes Gnus update the estimate with real information though. Making the Group buffer use the real values from the backend, when they are able to provide that data, should fix this problem and be very useful. Shouldn't be too difficult to do, I think. > I love everything Gnus does, and really want to use it as a front end > to this server - is there any way to write it a back end? I've > experimented a little, and it seems that Gnus generally requests much > more information than it uses, but checks too rarely (with, for > example, nnchoke-request-update-info) to keep the information > up-to-date. Is there any way to trick Gnus into letting the server > keep track of everything, or would it mean rewriting a significant > part of the front end? Are there any plans for allowing this in the > future? > > If I don't want to rewrite parts of Gnus, is it possible to write my > own group-browsing mode and connect it to the Gnus summary mode? If you implement `gnus-request-set-mark' your backend should at least receive all flags as set by Gnus. The other way is handled via `nnchoke-request-update-info', but I'd agree that this is called too many times and still not enough times. (This is way nnimap doesn't have a `nnimap-request-update-info' but rather calls this function internally upon group entry, in `nnimap-request-group' -- which doesn't seem to cause any problems.) > If you think this is not worth the work, is there any other email > back end that lets you instantly re-split tens of thousands of > messages? You could have a look at Wanderlust, maybe their backend interface is cleaner.