problem is that to convert back to msgno for an expunge response requires a lock on the source. COMPRESS can take the pain out of the actual protocol transmission. Maybe require VANISHED responses instead.
------ Original Message ------
From: "Timo Sirainen" <[email protected]>
To: "Adrien W. de Croy" <[email protected]>
Cc: "Discussion on drastically slimming-down IMAP." <[email protected]>
Sent: 31/05/2012 11:35:03 a.m.
Subject: Re: Re[2]: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE?
On 31.5.2012, at 2.07, Adrien W. de Croy wrote:



what about using the sequences in the final tagged response as an indication of 
what was actually successfully moved..  the ones that map source messages to 
new UIDs.
We suppress EXPUNGE responses during MOVE already.  When you're moving a large 
set of messages, this improves things quite a bit in terms of bw and speed.


It's doable of course, but I don't think it's worth the extra complexity for 1) 
the protocol specs and 2) client implementations. The bandwidth savings are 
pretty minimal.



I thought it was already there.




The COPYUIDs may or may not be there depending on UIDPLUS extension, but what 
isn't there is the requirement for clients to parse the UIDs and apply them 
internally as equivalent to EXPUNGEd UIDs. I see tons of problems with that. 
Probably nothing that couldn't be overcome by adding a lot of restrictions to 
the spec and to the client behavior, but it's really not worth the extra 
complexity.




_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5

Reply via email to