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