From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/86084 Path: news.gmane.org!not-for-mail From: Nikolaus Rath Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] Use IMAP MOVE extension if available Date: Sun, 02 Aug 2015 16:36:39 -0700 Message-ID: <87vbcx460o.fsf@vostro.rath.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1438558680 10944 80.91.229.3 (2 Aug 2015 23:38:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Aug 2015 23:38:00 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M34318@lists.math.uh.edu Mon Aug 03 01:37:49 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 1ZM2pA-0007Z6-5j for ding-account@gmane.org; Mon, 03 Aug 2015 01:37:48 +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 1ZM2oB-0003Z0-TO; Sun, 02 Aug 2015 18:36:47 -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 1ZM2oA-0003Yh-0g for ding@lists.math.uh.edu; Sun, 02 Aug 2015 18:36:46 -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 1ZM2o8-0007XC-Id for ding@lists.math.uh.edu; Sun, 02 Aug 2015 18:36:45 -0500 Original-Received: from ebox.rath.org ([45.79.69.51]) by quimby.gnus.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZM2o6-0002Lq-BV for ding@gnus.org; Mon, 03 Aug 2015 01:36:42 +0200 Original-Received: from vostro.rath.org (vostro [192.168.12.4]) by ebox.rath.org (Postfix) with ESMTPS id E535425B95 for ; Sun, 2 Aug 2015 23:36:39 +0000 (UTC) Original-Received: by vostro.rath.org (Postfix, from userid 1000) id 941F4EFBCC1; Sun, 2 Aug 2015 16:36:39 -0700 (PDT) Mail-Copies-To: never Mail-Followup-To: ding@gnus.org In-Reply-To: <87oaiqs067.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Sun, 02 Aug 2015 13:56:48 +0800") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) X-Spam-Score: -1.2 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:86084 Archived-At: 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=3D "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=3D "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? > 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. > 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. Best, -Nikolaus --=20 GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2= =AB