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
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
