From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/67291 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.gnus.general Subject: Re: gnus and imap Date: Mon, 25 Aug 2008 14:25:20 +0200 Message-ID: References: <877iabwtjx.fsf@randomsample.de> <87abf51c4m.fsf@marauder.physik.uni-ulm.de> <874p5dm35l.fsf@randomsample.de> <87iqttq7ja.fsf@randomsample.de> <87d4k0t7ga.fsf@randomsample.de> <87myj3wzp7.fsf@randomsample.de> <878wumqo7z.fsf@randomsample.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1219667247 18562 80.91.229.12 (25 Aug 2008 12:27:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Aug 2008 12:27:27 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M15742@lists.math.uh.edu Mon Aug 25 14:28:20 2008 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1KXbB0-0007Rl-OB for ding-account@gmane.org; Mon, 25 Aug 2008 14:28:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1KXb94-0001PZ-EL; Mon, 25 Aug 2008 07:26:06 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1KXb92-0001PF-Jv for ding@lists.math.uh.edu; Mon, 25 Aug 2008 07:26:04 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1KXb8M-00036h-KQ for ding@lists.math.uh.edu; Mon, 25 Aug 2008 07:26:04 -0500 Original-Received: from m61s02.vlinux.de ([83.151.21.164]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1KXb8N-0003X2-00 for ; Mon, 25 Aug 2008 14:25:23 +0200 Original-Received: from kafka.physik3.gwdg.de ([134.76.92.48]) by m61s02.vlinux.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1KXb8m-0005gn-Tj for ding@gnus.org; Mon, 25 Aug 2008 14:25:49 +0200 Mail-Copies-To: never Mail-Followup-To: ding@gnus.org In-Reply-To: (Vitaly Mayatskikh's message of "Mon, 25 Aug 2008 10:05:15 +0200") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2.90 (gnu/linux) X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:67291 Archived-At: Vitaly Mayatskikh writes: >> I also further searched through gmane for the problem of wrong article >> counts, since this topic came up frequently on the ding list. And lo and >> behold, there's stuff already in Gnus for this, it's just not documented >> in the manual. > > Wrong articles count is only one of problems. Getting old articles in > nnimap group is close to impossible: I can't just tell "give me last 5 > old articles", because Gnus calculates wrong uids for these > articles. Instead of it, I have to ask for last 1000 (or 10000, or > 100000) articles :( Well, this is a result of the wrong article count. Gnus simply uses (- (1+ (cdr active)) (car active)) i.e. highest-lowest as the number of articles in a group. Since Zimbra doesn't generate contiguous UIDs, this number is far too large. When you tell Gnus to get the latest 5 articles, it simply queries the back end with the UIDs from 'highest-4' to 'highest' - again assuming contiguous article numbers. This is why you have to query Gnus with insane numbers of articles, and of course this is slow, since the back end gets queried with the fully expanded sequence. > Also, I don't like any fixup hooks. Usually that means bad design of > software, and usually they don't fix the problem at all. At the moment, I see two options to get rid of this problem: 1) Make nnimap always return contiguous article numbers. Currently, nnimap simply uses the UIDs provided by the IMAP server as article numbers. We could change nnimap to use its own set of contiguous article numbers and map those to the UIDs of the IMAP server. The advantage would be that changes would be more or less confined to nnimap, but this also implies that other back ends wouldn't profit from this. 2) Make Gnus correctly deal with non-contiguous article numbers. Obviously, all back ends would profit from this, but this would mean (probably large) changes throughout the back end interface. We could use gnus-request-group-articles to get a list of all article numbers in a group (if the back end supports it). Gnus could calculate article counts from this (total as well as unread) and also query the back end with the correct sequence of article numbers. Other options? > I wish Gnus to cache all needed meta data, like other mail clients do. It > is really not necessary to ask for all seen/unseen uids again and > again, but rather to search uids since last update. Yes, caching would have to be done as well. We could use a new hash table for this. There's one for the nnimap-fixup function anyway... -David