wasm-demo/demo/ermis-f/imap-protocol/cur/1600095114.22960.mbox:2,S

44 lines
1.8 KiB
Plaintext

MBOX-Line: From dave at cridland.net Fri Nov 3 07:04:46 2006
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun 8 12:34:38 2018
Subject: [Imap-protocol] rfc4549
In-Reply-To: <1162561886.29374.42.camel@hurina>
References: <1162561886.29374.42.camel@hurina>
Message-ID: <14025.1162566286.648724@peirce.dave.cridland.net>
On Fri Nov 3 13:51:26 2006, Timo Sirainen wrote:
> Why does it suggest fetching new messages with <lastseenuid+1>:*?
> Hasn't
> this been discussed already several times here that it'll return the
> last message also, unneededly wasting bandwidth and server
> resources?
> Wouldn't <lastseenuid+1>:2147483647 be a better solution?
This will only happen if UIDNEXT has changed, but there are no
messages with a UID equal or higher than lastseenuid+1 - the document
clearly states that "[...] the former command should only be issued
if the UIDNEXT value cached by the client differs from the one
returned by the server."
In turn, this can only happen if new messages have arrived but have
also been expunged, and there are still messages in the mailbox. This
is pretty rare - in general, users don't expunge all the new messages
only, they either don't expunge many or else they expunge all the
messages in the mailbox entirely.
I suspect that your suggestion is therefore optimizing for a rare
case. (Even if it weren't, <lastseenuid+1>:<uidnext> would be better).
In fact, it's not only possible, but quite easy, to elide the FETCH
even in this rare case if you use SEARCH-based UID resynchronization,
since the client would detect earlier that the messages were expunged.
Dave.
--
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade