MBOX-Line: From iana at apple.com  Thu Mar 20 13:40:19 2014
To: imap-protocol@u.washington.edu
From: Ian Anderson <iana@apple.com>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] Detecting HIGHESTMODSEQ changes/polling for
 flag changes
In-Reply-To: <CAO3aFYvtP0Xst5tpG_UOL_PL8e7k7NSONp-2VPsf7HksenwLmw@mail.gmail.com>
References: <4E9EBB0E-ADFB-4F79-A27B-51ADC8395D71@apple.com>
	<CAO3aFYvtP0Xst5tpG_UOL_PL8e7k7NSONp-2VPsf7HksenwLmw@mail.gmail.com>
Message-ID: <97FD74F7-D332-4439-BC01-A2A2849463F8@apple.com>

OK cool, sounds like there?s at least a little precedent for this then.  Thanks.

Ian

On Mar 20, 2014, at 11:44 AM, Michael Grinich <mgrinich@gmail.com> wrote:

> We just poll STATUS for HIGHESTMODSEQ changes and then use FETCH CHANGEDSINCE. 
> 
> It works, but on large mailboxes that STATUS call can take a while (ie: minutes).
> 
> 
> 
> On Thu, Mar 20, 2014 at 11:32 AM, Ian Anderson <iana@apple.com> wrote:
> I?m finding it dismayingly common that servers don?t give flag changes (i.e. an untagged FETCH response with FLAGS) on a NOOP.  Some of them don?t support IDLE, or don?t give flag changes on IDLE either.  At least some of the servers do support CONDSTORE though.
> 
> So I was hoping to mitigate the whole mess by polling for HIGHESTMODSEQ changes on CONDSTORE servers and then doing a FETCH CHANGEDSINCE for mailboxes with new highest modification sequences.  For mailboxes that I?m not SELECTed on, it?s an easy STATUS HIGHESTMODSEQ command.  I can also do it on SELECTed mailboxes too, though RFC 3501 says I "SHOULD NOT? do that and RFC 4551 doesn?t update that recommendation.
> 
> What?s the conventional wisdom on solving this problem from the client side in a generic fashion?  My inclination is to just replace my NOOP polling with STATUS on servers that support CONDSTORE.
> 
> Ian
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140320/720adc73/attachment.html>
