From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/71849 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: nnimap issues Date: Sun, 26 Sep 2010 18:17:16 +0200 Organization: Programmerer Ingebrigtsen Message-ID: References: <878w2olqoa.fsf@mocca.josefsson.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1285517874 25174 80.91.229.12 (26 Sep 2010 16:17:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 26 Sep 2010 16:17:54 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M20222@lists.math.uh.edu Sun Sep 26 18:17:52 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 1OztvC-0006X1-IN for ding-account@gmane.org; Sun, 26 Sep 2010 18:17:50 +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 1Oztuw-0007Rt-Ie; Sun, 26 Sep 2010 11:17:34 -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 1Oztuu-0007Rc-5m for ding@lists.math.uh.edu; Sun, 26 Sep 2010 11:17:32 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1Oztup-0000xC-NU for ding@lists.math.uh.edu; Sun, 26 Sep 2010 11:17:32 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1Oztuo-0000x6-00 for ; Sun, 26 Sep 2010 18:17:26 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Oztum-0006SW-V9 for ding@gnus.org; Sun, 26 Sep 2010 18:17:24 +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 ; Sun, 26 Sep 2010 18:17:24 +0200 Original-Received: from larsi by cm-84.215.34.171.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 Sep 2010 18:17:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 82 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.215.34.171.getinternet.no Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEVpnyFsoiBooCJVHyVq oR5nnyFnnSGPs1JnlyRpaDMPlJWjAAACX0lEQVQ4jVWQPW/bMBCGaTUJ0M0UtHSzWUhIx/aGmltU EK7HQAiFjoZjEfbsgdXYGAisMRYQif82d6RUJyfwQ/fwvS9mzNoEW6tluKRmE82ZMdsBbNmyui7x IiotCIy2XSMwpalEpgsRwO55gDe0ZcZUG2ba1+MCP4BXc4QFrp5OAj0QkiBX4OAETu7wfELgpCFN Aw0Y1yBqYOcIQAD4FkDuZTgpFMDzCBwcZThJsfA5fKiTz0Ln+V1VPimhMfnrXv4vV2JkKllig1t1 af7kl85OUcxM45w74dY7uu1xNSfXP7Eb10rXtAQcXgk+9tKdEQzW+70Z1pmxO/VuwmWlS4E2F4xN 1JXJ1jhW9FU4b/KKmMCUsbJi11oXukj98zgAPmVCzFihRUrvSTHnHrAI/wr0DoDHnMdsNuE88v/B S4ATQBnGxFhFMTIezzlnAhXx+D4NwOegTacUXo9gToylE45uoTdYLspuWzh7ESWfRdlGCK1Rcgto qKHkOZ9GWaHvI/QXRwI/fFWM82lWVuWD74L8IKleNkOgyzUmSLX44wHMCaCC0/QiUnwL4GVQ8Gu9 vo9I8RVcd5DwncBVzpO7lDE1mT38+vTTtuDaxQjUnZrkuXrIP1toZX2oCSQEBktWrnZdbTsCKufq Yp11nbVuAEGR41p60AWgBkDCpbU1Kv5+UCQhlK2tfQkgSbzbgwbL7ep/Y6gkz3mee5ltscWgUKRA 6BW8O9Sd7EMoX1ISFPzRYiuhqkt/FOqLraHtXgi89yvlrKwd1cs+uNWq9vXixsYOgv0+WNsRsOwy D3pxAW95oEhGx296FQAAAABJRU5ErkJggg== Mail-Copies-To: never X-Now-Playing: Kid 606's _Songs About Fucking Steve Albini_: "Periled Emu God" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:nR70v+S0TESLhUveFWGShY/6iMY= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:71849 Archived-At: Simon Josefsson writes: > The 'UID FETCH 1:*' command is an O(n) operation (both in terms of > computation on client and server side but also on bandwidth) on the size > of the mailbox, and for large mailboxes this becomes really painful. It > can results in MB's of data being pushed every time I press 'g'. It only requests the last 100 flags... > The old nnimap used the STATUS command to look for new mail instead. > There are controversies over whether this is a good idea or not, but > older IMAP RFCs support it and as far as I know, it is the fastest and > most reliable way to check for new mail. Alternatively, doing a 'UID > FETCH 1,*' should be an O(1) operation. > > Generally, why is it downloading all the flags on all messages over and > over again? It should have all that cached anyway, except for possibly > new messages. Before starting working on this, I was trolling the gnus-bug group, and it seemed like the most constant complaint was "why is nnimap showing 30 unread messages while there's really only 2"? I think the only way to actually tell how many new messages have actually arrived when UIDNEXT jumps from X to X+N is to do a UID FETCH X:*, isn't it? (Please correct me if I'm mistaken -- I'm not an IMAP expert). So Gnus requests (- X 100):*, to just double-check whether any of the most recent messages have changed their flags, too. So the primary reason for the flag fetch isn't really to get the flags (although that's a nice side-effect), but to find out how many new articles there are in the mail box. If there's a faster way to do this, I'd love to hear it. (Oh, there's QRESYNC, which might speed stuff up, but I haven't implemented that yet.) > 2) Nnimap no longer auto-discover that my server supports STARTTLS and > instead tried to use direct TLS, which obviously fails since my IMAP > server doesn't speak native TLS on the vanilla IMAP port. I had to add > 'nnimap-stream starttls' to my select method manually. STARTTLS is the > recommended way to do TLS with IMAP so it would be nice to make this > work automatically. Yes, it should check the capabilites and auto-STARTTLS if it's available, I guess? > 3) When imap-log is non-nil, the *imap-log* buffer no longer contains > the output from the server, which makes debugging harder. I was planning on getting rid of the log buffer totally when it works perfectly. Any day now! :-) > 4) Nnimap mail splitting is not working any more. All my e-mail sits in > INBOX and there is no filtering going on. I don't see anything in > GNUS-NEWS about any change in this area, so it must be a bug. :-) :-) I've now added a mention, but it's mostly related to the new nnimap-inbox variable, and using the standard nnmail-split-methods. > > 5) Selecting a IMAP group results in two SELECT operations? From > *imap-log*: > > 09:34:53 2012 SELECT "INBOX.yxa-staff" > 09:34:54 2013 SELECT "INBOX.yxa-staff" That looks like a bug. I'll fix it... > 6) Deleting messages doesn't compress the article list, which for large > operations may result in too long lines: > > 09:35:05 2016 UID STORE 6309,6310,6311,6312,6313,6314,6315 +FLAGS.SILENT (\Deleted) > 09:35:06 2017 UID EXPUNGE 6309,6310,6311,6312,6313,6314,6315 > 09:35:08 2018 UID STORE 6309:6315 +FLAGS.SILENT (\Seen) Yup; fixed. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen