On Wed, 5 Nov 2003, Arnt Gulbrandsen wrote: > No such guarantee would be necessary. Consider this: > > C: a search subject "make.money.fast" > S: * search 101 942 > C: 1 fetch 101,942 ... > S: * fetch 101 ... > S: * fetch 942 ... > S: 1 ok > S: * search 327 > S: a ok > C: 2 fetch 327 ... > C: * fetch 327 ... > C: 2 ok > > Command a could go on one server connection, commands 1 and 2 on > another. Or, technically they could go on the same, since IMAP permits > the server to execute multiple commands concurrently. Or the client by > chance have 101, 327 and 942 all in cache.
I agree that for SEARCH you don't need any ordering guarantees and this approach is reasonable. Of course, you can't issue fetch response on a separate connection unless you are certain that the sequence numbers are synced on the two connections (then again, using UID search is probably fine, as long as you can deal with the occasional message that hasn't been declared yet). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski | Andrew Systems Group * Research Systems Programmer PGP:0x5CE32FCC | Cyert Hall 207 * [EMAIL PROTECTED] * 412.268.7456 -----BEGIN GEEK CODE BLOCK---- Version: 3.12 GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++(++++) E W+ N o? K- w O- M-- V-- PS+ PE++ Y+ PGP+ t+@ 5+++ R@ tv-@ b+ DI+++ G e++ h r- y? ------END GEEK CODE BLOCK-----
