Re: [Imap-protocol] Multiple non-waiting UID SEARCH commands
Timo Sirainen <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[email protected]> |
On 21.8.2013, at 13.26, Lasse Jansen <[email protected]> wrote: > UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting > command sequence, depending upon whether or not the second UID > SEARCH contains message sequence numbers. > > > As none of the commands contain message sequence numbers, I would say this should be allowed. It is. However it doesn't say anything about the order in which the replies should arrive. So it would make sense only when you just want to combine multiple SEARCHes into one results. > With Gmail and Courier-IMAP everything seems to work fine, but with Dovecot, although both the tagged and untagged responses have the correct order within their category in my testing, sometimes an untagged response is sent before the tagged response of the preceding command: > > 1 UID SEARCH UNSEEN > 2 UID SEARCH FLAGGED > 3 UID SEARCH DELETED > * SEARCH 33085 > 1 OK Search completed (0.000 secs). > * SEARCH > * SEARCH > 2 OK Search completed (0.000 secs). > 3 OK Search completed (0.000 secs). > > But this should be fine as long as I can rely on the order of the untagged responses. For the above SEARCH commands it's very likely that you receive the untagged responses in the correct order, but I don't think it's guaranteed. Dovecot attempts to process SEARCH commands 0.1 seconds at a time, then see if there's some other work to do, handle that and go back to processing SEARCH. So for example if the first SEARCH was using BODY/TEXT in a large enough mailbox, the 2 and 3 SEARCH replies could be finished and returned first. The tagged replies are always returned in order, because Mail.app used to break if they weren't. FETCH command is handled in somewhat similar way. It gets processed until the client output buffer gets full, then Dovecot sees if there's some other work to be done while waiting, possibly starting another FETCH command that starts mixing the results with the first one. With FETCH this shouldn't cause any trouble though. _______________________________________________ Imap-protocol mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol