From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/70745 Path: news.gmane.org!not-for-mail From: Daniel Pittman Newsgroups: gmane.emacs.gnus.general Subject: Re: That newfangled IMAP thing... Date: Sun, 12 Sep 2010 18:38:40 +1000 Message-ID: <874odv4ar3.fsf@rimspace.net> References: <87hbi3jasy.fsf@lifelogs.com> <87pqwmsusz.fsf@news.realpath.org> <8762yd6j4j.fsf@rimspace.net> <87eid0fsil.fsf@lifelogs.com> <87bp84y00w.fsf@keller.adm.naquadah.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1284281542 28113 80.91.229.12 (12 Sep 2010 08:52:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 12 Sep 2010 08:52:22 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M19118@lists.math.uh.edu Sun Sep 12 10:52:21 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 1OuiIP-0002NP-4z for ding-account@gmane.org; Sun, 12 Sep 2010 10:52:21 +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 1OuiID-00059M-I0; Sun, 12 Sep 2010 03:52:09 -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 1OuiIB-000593-FQ for ding@lists.math.uh.edu; Sun, 12 Sep 2010 03:52:07 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1OuiI7-0001s9-0m for ding@lists.math.uh.edu; Sun, 12 Sep 2010 03:52:07 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1OuiI6-00064x-00 for ; Sun, 12 Sep 2010 10:52:02 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OuiI6-0002Kk-8r for ding@gnus.org; Sun, 12 Sep 2010 10:52:02 +0200 Original-Received: from ppp59-167-189-244.static.internode.on.net ([59.167.189.244]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Sep 2010 10:52:02 +0200 Original-Received: from daniel by ppp59-167-189-244.static.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 12 Sep 2010 10:52:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 53 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ppp59-167-189-244.static.internode.on.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Cancel-Lock: sha1:StKUIfObcwtcHyoKANIDWU0Mgyk= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:70745 Archived-At: Lars Magne Ingebrigtsen writes: > Lars Magne Ingebrigtsen writes: > >> Next I'll do group entry and article selection, and then it's time to >> implement the new group info function that will return real ranges of >> unread/read/unseen articles directly to Gnus without going via the *nntpd* >> buffer. It might be called... er... `nnimap-request-group-data'? > > Eurhm. I'm reading the RFC, and I'm wondering whether I'm seriously > missing something. > > Is the client supposed to do a > > EXAMINE foo > FETCH 1:* (FLAGS) > > on each single mailbox to get all the article data? Kind-of. Plain-jane IMAP is really bare about these things; what you want to do is query capabilities from the server at startup, then select the appropriate mechanisms for action from that. For example, the EXPUNGE after sync discussed elsewhere probably means you want to demand (unconditionally, because nothing doesn't implement) UIDPLUS from the server. That adds a bunch of UID versions of commands that otherwise need to reflect the id in the current fetch, making life *much* faster for you. Anyway, to sync flags you want this: https://tools.ietf.org/html/rfc5162#section-5 That would be the official upstream documentation about the QRESYNC variant of the "flag sync" process, and includes how to handle less capable servers. Given that "less capable" means "most" — since only Zimbra has QRESYNC that I deal with regularly... Anyway, CONDSTORE capability is pretty routine, and most things will have that; I would suggest you stash away a pointer to the right routine somewhere in the server thing every login, after doing a capabilities query. > If you have a million emails on the server (and who hasn't?), that'll like > take forever. Fer sure. Yah. CONDSTORE makes it much faster. Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons