From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/72001 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap issues Date: Mon, 27 Sep 2010 19:20:39 +0200 Organization: Programmerer Ingebrigtsen Message-ID: References: <878w2olqoa.fsf@mocca.josefsson.org> <87y6anw8rq.fsf@mocca.josefsson.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1285608061 1681 80.91.229.12 (27 Sep 2010 17:21:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 27 Sep 2010 17:21:01 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M20374@lists.math.uh.edu Mon Sep 27 19:21:00 2010 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.69) (envelope-from ) id 1P0HNq-0007eJ-02 for ding-account@gmane.org; Mon, 27 Sep 2010 19:20:58 +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 1P0HNo-00024m-VH; Mon, 27 Sep 2010 12:20:57 -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 1P0HNn-00024U-4K for ding@lists.math.uh.edu; Mon, 27 Sep 2010 12:20:55 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1P0HNi-0006fu-Mr for ding@lists.math.uh.edu; Mon, 27 Sep 2010 12:20:55 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1P0HNi-0005wC-00 for ; Mon, 27 Sep 2010 19:20:50 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P0HNe-0007YC-Px for ding@gnus.org; Mon, 27 Sep 2010 19:20:46 +0200 Original-Received: from cm-84.215.34.171.getinternet.no ([84.215.34.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Sep 2010 19:20:46 +0200 Original-Received: from larsi by cm-84.215.34.171.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Sep 2010 19:20:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 64 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.215.34.171.getinternet.no Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAALVBMVEWfnJv7+vjQzczf2NTl 4N19dXMaFRXz8e3////+//79/f3Fwb+PjIqwrar+/v3goG/KAAABUElEQVQ4jWN40YEAlQhmJwNI orOjcwWIV4GkiGEm75k9B86eiQRxJJAlZjAcuMBw9MwJTAllZ20nJesKDImXvDEX9sRGd2BKHGBl 2MN7CMyRQzFqs9EmJaC7MCV4jm49DeWgSty9cPs2NomO3ZfucjOA2e2OL5AlYk7fiYVICJtYIEl0 am/ZorR71Uqghkslfsg6ZsKYTSyCW5Al4KD7Srk1dgmWiXslsEm8DRK0qcAmIcpduMcCm0RpUKGK JVYJZuWLWHWYhrvv9MQqweKiiV3H4eqdWO24s6XY0wObhM/tox5YJY7F8M7AZnl7WlrqDGyWt4Sl pVVgddWctDQJrK4SwyVRmpamiSTxAmF7bRon1iBpKWSrwirRKFXdiVWiD5hSsEqsWoFD4iXQHV7Y JICgEyTRBZGYgSKDS0eHIy4J0nXglOggX6IPt8QL7BLzAMKlTrt2lMRIAAAAAElFTkSuQmCC Mail-Copies-To: never X-Now-Playing: Circlesquare's _Songs About Dancing And Drugs_: "Dancers" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:vBnDYNbw7W9zSMkdxNdPf/K1yBI= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:72001 Archived-At: Simon Josefsson writes: > Then I wonder if it is the EXAMINE or the UID FETCH that is taken time, > compared to the old approach of using STATUS. On some servers the EXAMINE itself is slow, while on others it's fast. > As I recall, this isn't specific to nnimap, and happens for all backends > if there are holes in the article range. Yes. IMAP is unique, though, in that some servers have very sparse article numbers, and that people read/delete messages from different user agents routinely, and expect this to be reflected in all the user agents... > But does it have to EXAMINE+FETCH all groups unconditionally? I think > it does that, right? It could use the old approach with STATUS to > quickly see what mailboxes have changed at all, and then for those > (hopefully few) mailboxes that have changed, do the EXAMINE+FETCH dance. But the problem is that STATUS will only say whether you've gotten a new message, not whether you've read/deleted some of the messages via a different user agent... > Ah. I think I got it: the old code sent the STATUS in parallel, like this: > > 1554 STATUS "INBOX.sent-2010" (UIDVALIDITY UIDNEXT UNSEEN) > 1555 STATUS "INBOX.sent-2009" (UIDVALIDITY UIDNEXT UNSEEN) > 1556 STATUS "INBOX.fossgrupp" (UIDVALIDITY UIDNEXT UNSEEN) > 1557 STATUS "INBOX.apel-en" (UIDVALIDITY UIDNEXT UNSEEN) > > and then waits for all the replies. The new code iterates through all > groups and does EXAMINE+FETCH on each of them. > > What is biting now may be all the round trips. No, they're still being streamed, like the old code. nnimap now issues a bunch of EXAMINE+FETCH commands, and then waits for the last response to trickle in. (Well, it usually doesn't wait, because this is now issued early in the `g' cycle, so if you have other servers (like NNTP or whatever), it'll issue the nnimap stuff first, then wait for the NNTP stuff, and then look whether the IMAP stuff has arrived...) However, it would make sense to allow the user to twiddle this. If the user only reads the IMAP groups from a single Gnus instance, then STATUS would be fine. Is that very common, though? > 1) Parallel STATUS like the old code to discover which groups have been > changed at all. > > 2) For those groups that have changed, do the EXAMINE+FETCH dance. That would be possible, but then it'd have to wait for the STATUS responses to arrive before doing any EXAMINE+FETCH stuff, which doubles the round trips... > That idiom brings back memories. Glad to have you back working on Gnus, > Lars! It's fun to be back. :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen