From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/86085 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] Use IMAP MOVE extension if available Date: Mon, 03 Aug 2015 08:40:01 +0800 Message-ID: <87d1z5cihq.fsf@ericabrahamsen.net> References: <87io9l2bd0.fsf@vostro.rath.org> <87y4ibf93c.fsf@ericabrahamsen.net> <87wpxuerau.fsf@thinkpad.rath.org> <878ua2cj3m.fsf@ericabrahamsen.net> <87r3nta8e8.fsf@thinkpad.rath.org> <87oaiqs067.fsf@ericabrahamsen.net> <87vbcx460o.fsf@vostro.rath.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438562464 29894 80.91.229.3 (3 Aug 2015 00:41:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Aug 2015 00:41:04 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M34319@lists.math.uh.edu Mon Aug 03 02:40:52 2015 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from lists1.math.uh.edu ([129.7.128.208]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZM3oA-0004SC-Lc for ding-account@gmane.org; Mon, 03 Aug 2015 02:40:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.85) (envelope-from ) id 1ZM3nY-0003sI-Hj; Sun, 02 Aug 2015 19:40:12 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1ZM3nV-0003rz-NX for ding@lists.math.uh.edu; Sun, 02 Aug 2015 19:40:09 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZM3nU-0007mt-Fr for ding@lists.math.uh.edu; Sun, 02 Aug 2015 19:40:09 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1ZM3nS-0003qU-3M for ding@gnus.org; Mon, 03 Aug 2015 02:40:06 +0200 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZM3nR-0004L2-N3 for ding@gnus.org; Mon, 03 Aug 2015 02:40:05 +0200 Original-Received: from 222.129.224.133 ([222.129.224.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Aug 2015 02:40:05 +0200 Original-Received: from eric by 222.129.224.133 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 03 Aug 2015 02:40:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 118 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 222.129.224.133 User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:A+UIShxMMpQyE372u6ZM5WQcE84= X-Spam-Score: 0.2 (/) X-Spam-Report: SpamAssassin (3.4.1 2015-04-28) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-1503--66395h-0s--0d--git, 0.000-1442--63672h-0s--0d--100644, 0.000-332--14643h-0s--0d--PATCH, 0.000-37--1620h-0s--0d--formats, 0.000-33--1458h-0s--0d--explicit Spam tokens: 0.994-8497--301h-6009s--0d--Hx-spam-relays-external:quimby.gnus.org, 0.994-8497--301h-6009s--0d--H*RU:quimby.gnus.org, 0.994-8017--286h-5671s--0d--HTo:D*gnus.org, 0.992-8429--369h-6009s--0d--Hx-spam-relays-internal:80.91.231.51, 0.992-8429--369h-6009s--0d--H*RT:quimby.gnus.org Autolearn status: no autolearn_force=no -1.0 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [80.91.229.3 listed in list.dnswl.org] -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 2.0 FSL_HELO_BARE_IP_2 No description available. List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:86085 Archived-At: Nikolaus Rath writes: > On Aug 02 2015, Eric Abrahamsen wrote: >> Nikolaus Rath writes: >> >>> On Jul 27 2015, Eric Abrahamsen wrote: >>>> diff --git a/lisp/nnimap.el b/lisp/nnimap.el >>>> index 161a6b4..f8e6e3e 100644 >>>> --- a/lisp/nnimap.el >>>> +++ b/lisp/nnimap.el >>>> @@ -489,11 +489,18 @@ textual parts.") >>>> (when (functionp (nth 2 credentials)) >>>> (funcall (nth 2 credentials))) >>>> ;; See if CAPABILITY is set as part of login >>>> - ;; response. >>>> - (dolist (response (cddr login-result)) >>>> - (when (string= "CAPABILITY" (upcase (car response))) >>>> - (setf (nnimap-capabilities nnimap-object) >>>> - (mapcar #'upcase (cdr response)))))) >>>> + ;; response. If it wasn't, specifically request >>>> + ;; it. >>>> + (when >>>> + (catch 'caps >>>> + (dolist (response (cddr login-result)) >>>> + (when (string= "CAPABILITY" (upcase (car response))) >>>> + (throw 'caps (setq capabilities (cdr response))))) >>>> + (let ((req (nnimap-command "CAPABILITY"))) >>>> + (when (car req) >>>> + (throw 'caps (setq capabilities (cdaddr req)))))) >>>> + (setf (nnimap-capabilities nnimap-object) >>>> + (mapcar #'upcase capabilities)))) >>>> ;; If the login failed, then forget the credentials >>>> ;; that are now possibly cached. >>>> (dolist (host (list (nnoo-current-server 'nnimap) >>> >>> >>> This looks a lot more complex, but as far as I can tell it still >>> needlessy asks for capabilities if they have been supplied in the >>> response code of OK response instead of a in separate, untagged >>> response. So is it really worth the extra complexity, if in many cases >>> we still issue an explicit CAPABILITY command? >>> >>> (For everyone unfamiliar with RFC3501, what I mean is that this: >>> >>> * CAPABILITY IMAP4rev1 AND SOME MORE \r\n >>> 1 OK Logged in\r\n >>> >>> will be parsed correcly but this: >>> >>> 1 OK [CAPABILITY IMAP4rev1 AND SOME MORE] Logged in\r\n >>> >>> will still cause Gnus to issue a separate CAPABILITY command). >> >> Okay, I pushed the CAPABILITY patch, and the MOVE patch right after >> that. Sorry this is all going so slowly! > > Don't worry, I'm not in a rush. Luckily I can run the patches locally > until they applied upstream :-). > >> I still think that we'll be able to come up with something that doesn't >> unconditionally issue an extra CAPABILITY command. My patch was more >> complex, but at least it avoided redundancy in *some* cases -- now we're >> always doing the extra command. > > I don't understand this worry about one additional back and forth during > *login*. For me, starting Gnus takes about 2 seconds, and issuing the > CAPABILITY command takes about 160 ms. Is it really worth optimizing > this? No, I guess you're right. It just irks, a little. >> Are you sure that `nnimap-parse-response' and `nnimap-parse-line' can't >> handle the bracket case above? > > Depends what you mean. The data does end up in the list that's returned > by nnimap-parse-response, because (as the comment says), it just > "lightly" converts the response to a list of strings and lists of > string. The problem is the "lightly" - apparently this function > "succeeds" no matter what data you give it, even if this data completely > fails the assumptions that went into writing that function. Looking at > the code, I am not able to tell (in general) at which position the > response code is going to be. So the best I can do is just use the > location at which it ends up with my server - but I don't think that's a > good idea. > > That's also the reason why I did not use nnimap-parse-response at all > for parsing the NAMESPACE command (in my other patch). In that case, > "parsing" the return value of nnimap-parse-response is actually a lot > harder than parsing the IMAP response directly. For example, the > nnimap-parse-response return value contains strings with opening parens, > but no strings with the corresponding closing parens. > >> I haven't had time to test yet, but looking at the code it seems like >> it ought to be able to handle it. If there are multiple commonly-used >> formats for IMAP server responses, it seems like we really ought to be >> handling them at the base level, when parsing responses. > > Making nnimap-parse-response into a proper parser would certainly be a > good idea, but that's probably better left as a separate patch. Oh certainly -- I'm not in any hurry to get stuck into that! But at some point, yes, it would probably be nice. >> I'll admit I only started learning about IMAP about six months ago, so >> I'm happy to take other people's word on how all this works. Out of >> curiosity, is there a particular server that returns the kind of >> response you note above? I suppose we should be making a list of >> known-good IMAP servers that Gnus can interact happily with. > > This is mail.messagingengine.com, the IMAP server from > www.fastmail.com. IIRC they are using Cyrus. That's pretty mainstream stuff, and I've heard Cyrus referred to as one of the "sane" IMAP servers, so we should definitely be trying to play nice with it... Thanks, Eric