MBOX-Line: From brong at fastmail.fm  Sun Nov 13 12:56:59 2011
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] [noob] multiple fetch responses for the same
	message?
In-Reply-To: <755EBF71-00B6-4A4A-940A-CA8B5B62B10D@mac.com>
References: <43724F01-C3E3-4039-8919-51E528C56C54@mac.com>
	<1321215266.30428.140660998383617@webmail.messagingengine.com>
	<755EBF71-00B6-4A4A-940A-CA8B5B62B10D@mac.com>
Message-ID: <20111113205659.GA27151@brong.net>

On Sun, Nov 13, 2011 at 09:37:48PM +0100, Petite Abeille wrote:
> >> * 1 FETCH (FLAGS (\Seen))
> >> * 1 FETCH (RFC822.SIZE 44827)
> On Nov 13, 2011, at 9:14 PM, Bron Gondwana wrote:
> 
> > Compliant or not, I can bet you it will break a lot of clients.
> 
> But, on the other hand, doesn't it happen already? For example when a BODY fetch triggers a FLAGS fetch? 
> 
> ABC 1 FETCH (BODY[HEADER] )
> * 1 FETCH (BODY[HEADER] {342}
> ...
> * 1 FETCH (FLAGS (\Seen))
> ABC OK FETCH completed

Not with Cyrus - we collect up all the data about which fetches will
be required first, and then iterate the mailbox, spitting them out
in order.

This is quite specific, and for a reason - we calculate what flag
changes might be needed and do them with a mailbox lock, then we
release the lock before sending the response, so that other clients
are not waiting on the lock while network traffic is going on.

But it does have the other advantage of never generating duplicate
FETCH responses too.

Bron.

