Re: [PATCH] Use IMAP MOVE extension if available

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Nikolaus Rath <Nikolaus@rath.org> writes:

> On Jul 27 2015, Eric Abrahamsen <eric@ericabrahamsen.net> 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!

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.

Are you sure that `nnimap-parse-response' and `nnimap-parse-line' can't
handle the bracket case above? 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.

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.

Yours,
Eric