[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LC results for draft-melnikov-imap-expunged and how to move forward
On Tue Sep 26 00:52:45 2006, Ken Murchison wrote:
Randall Gellens wrote:
I admit to still being confused, since based on side discussions I
thought the server didn't need to store any state but would just
report to the client which messages in the set no longer exist.
This was my understanding as well, based on a private discussion
with Alexey prior to hacking up an implementation for Cyrus.
Your understanding on -01 is perfectly correct.
-00, however, required some kind of tombstone record, effectively
linking each EXPUNGE event with a MODSEQ. (Or each EXPUNGEd message
with a MODSEQ, if you prefer to look at things that way).
Alexey is suggesting - I think - that the client has some means of
saying "I want to know what messages have been EXPUNGEd since X
within UID set A", and the server can respond with one of the
a) "Here's a set of UIDs which have been EXPUNGEd since X".
b) "Sorry, I can't remember, you'll have to figure it out another
c) "I don't know, but here's a list of all UIDs in set A which do not
Now, the current state of affairs is that the server always responds
with (c). In -00, the server always responded with (a) [I think]. The
ACAP method [DELETEDSINCE if you care to look it up] went for (a)
with a fallback to (b).
Alexey's suggestion is (a) with a fallback to (c), since whichever
way it works, the client always has the resynch within one RTT.
I firmly believe we do need some fallback from (a). I agree it's
entirely unreasonable to expect a server to maintain significant
extra state. By providing a fallback, we can allow server
implementors to turn the retention of the state into a QOI issue.
However, I'm not sure what the fallback should be - (b) uses less
bandwidth, but - potentially - more round-trips. (c) uses more
bandwidth - potentially much more bandwidth - but uses no additional
So it's a trade-off, and it might even be worthwhile to have this as
a client-driven option. Certainly I'd really like to hear other
client developers' view on this. Myself, I'm undecided between an
option and (b). (c) has high costs for large, sparse mailboxes - to
give a real-world example, the ESEARCH response for "UID SEARCH
RETURN (ALL) 1:*" on my personal INBOX is 24k, or 9.5k when gzipped.
By comparison, I've used 12.95k of download so far this morning
That said, for compact mailboxes, irregardless of size, its very
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxx
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade