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.
On 31.5.2012, at 0.11, 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. > > ---- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com > WinGate 7 is released! - http://www.wingate.com/getlatest/ > > > > ------ Original Message ------ > From: "Timo Sirainen" <[email protected]> > To: "Cyrus Daboo" <[email protected]> > Cc: "Discussion on drastically slimming-down IMAP." <[email protected]> > Sent: 31/05/2012 5:27:22 a.m. > Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned during > UID MOVE? >> On 30.5.2012, at 20.20, Cyrus Daboo wrote: >> >> >>>>> >>>>> So Arnt tells me. >>>>> >>>> >>>> >>>> If I can implement it this way without violating the spec: >>>> >>>> 1. Verify that ACLs allow expunge, fail if not >>>> 2. Do atomic UID COPY without enforcing quota limits >>>> 3. Expunge the messages >>>> [4. If expunge for some strange reason fails now, there are probably >>>> duplicates now. I'm not sure if I want to bother fixing that situation. >>>> It should "never" happen anyway.] >>>> >>>> then I could add it to Dovecot pretty much immediately. >>>> >>> >>> >>> So if the expunge does fail, how are you going to report that to the >>> client? Arnt's current spec does not show any * N EXPUNGE responses coming >>> back, so I am assuming that the client is supposed to implicitly assume the >>> expunges took place, which would cause a problem if they did not take >>> place. But that seems wrong to me - shouldn't UID MOVE cause * N EXPUNGE to >>> be sent for each message that was actually moved? >>> >> >> >> I assumed that this was a bug in the example and was going to report it as >> some point. I think the EXPUNGE/VANISHED replies should be sent in any case, >> even if MOVE was required to be fully atomic. Otherwise if the UID MOVE >> command sends an untagged FETCH/EXPUNGE reply it wouldn't be obvious if the >> sequence number referred to the state before or after the MOVE expunges. >> >> _______________________________________________ >> imap5 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/imap5 >> >> > > _______________________________________________ > imap5 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/imap5 > _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
