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

