28 lines
1.2 KiB
Plaintext
28 lines
1.2 KiB
Plaintext
MBOX-Line: From arnt at gulbrandsen.priv.no Fri Jan 21 01:08:25 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
|
Date: Fri Jun 8 12:34:45 2018
|
|
Subject: [Imap-protocol] UIDNEXT updates upon new message arrival
|
|
In-Reply-To: <28835.1295567529.285091@puncture>
|
|
References: <4D385AB5.90208@gentoo.org> <28835.1295567529.285091@puncture>
|
|
Message-ID: <4D394D09.50406@gulbrandsen.priv.no>
|
|
|
|
On 01/21/2011 12:52 AM, Dave Cridland wrote:
|
|
> Most of this algorithm dates from a time when there was a real emphasis
|
|
> on reducing the actual octet count - I don't think that's the case so
|
|
> much anymore, so it's probably overkill.
|
|
|
|
I have a feeling that it's based on a description I wrote of a handheld
|
|
client I also wrote, ten years ago. At the time handhelds had negligible
|
|
RAM and less bandwidth.
|
|
|
|
Last year I started porting that to Android (I have a Galaxy S and hate
|
|
both of the MUAs there) and dropped this algorithm. Instead I ask for
|
|
VANISHED if available, and if it isn't available. handle EXPUNGES in a
|
|
somewhat Texan manner... when EXPUNGE arrives, I issue "UID SEARCH UID
|
|
x,y,z" for the entire set of messages I have in cache, and use the
|
|
search result to clean the cache. Primitive, simple, good enough.
|
|
|
|
Arnt
|
|
|