Re: [Imap-protocol] Multiple non-waiting UID SEARCH commands
Jan Kundrát <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[email protected]> |
On Wednesday, 21 August 2013 12:26:50 CEST, Lasse Jansen wrote: > As none of the commands contain message sequence numbers, I > would say this should be allowed. In my understanding of the RFC, even though you are allowed to send this, the result you get might not match your expectations, as others have explained in this thread. The command to implement here is ESEARCH which: a) solves your pipelining problem neatly and properly, b) allows for further compression of the result via the min:max syntax, c) is nowadays supported even by GMail Furthermore, if your IMAP server supports CONDSTORE (again, GMail nowadays does), you can save yourself some traffic during the flag resynchronization by using FETCH CHANGEDSINCE. There is one more uncertainity with the SEARCH response -- some sources (see the whole thread at [1]) support the interpretation that it is OK to actually send the SEARCH data for a single command split into multiple responses which are to be joined by the client. I wonder if this is valid. My understanding of RFC3501 wording is that such behavior is *not* correct and that there should always be exactly one SEARCH response to each SEARCH command, but my client will join them anyway. I wasn't able to pinpoint some authoritative source which made me change this, unfortunately. With kind regards, Jan [1] http://www.mail-archive.com/[email protected]/msg02127.html -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ _______________________________________________ Imap-protocol mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol