Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE?

[Arnt Gulbrandsen <[e-mail]>]

Sorry about my bad temper earlier this morning.

On 05/31/2012 10:58 PM, Adrien W. de Croy wrote:
> Even though we have to send EXPUNGEs to any other connected
> client on that mailbox (that didn't do the move), the approach is a bit
> wasteful of bandwidth etc.
>
> If you issue a command, you want to know when it's done and how it
> turned out.  If the MOVE completes in its entirety without issue (99.99%
> of the time), then  a simple "yeah it worked" response is the most
> efficient.  We can inform of exceptions, e.g. "something broke", or
> "these messages didn't work".  In the end, if there's a failure so what
> if the client has to resynch indices.

IMAP is a bit wasteful of bandwidth in many ways. We have a goodish 
solution for that, RFC 4978, and it's fairly well deployed. Of course we 
might add Microsoft-like special rules to lessen the pain by each 
particular instance of bandwidth waste, but since we already have a 
goodish solution for all of them, why bother?

I think that if you really want to not send EXPUNGE, you should provide 
some numbers to argue your case. Take the log files from some server, 
analyse the moves. How many messages are affected, and how many bytes 
would be sent on average for those commands when a) EXPUNGE is used b) 
EXPUNBGE+COMPRESS=DEFLATE c) VANISHED+C=D and d) nothing.

I suspect that b and c will be very, very close to d.

(FWIW, the easiest way to simulate b/c is to massage an IMAP session so 
you get a file containing just what the server sends, and then just 
'gzip -1' the prefix up until VANISHED/COMPRESS and until just after 
that, and look at the size difference. It won't be exact, but fairly 
good. Or 'gzip -4' or even -9.)

Arnt