MBOX-Line: From mgrinich at gmail.com  Thu Mar 20 11:44:51 2014
To: imap-protocol@u.washington.edu
From: Michael Grinich <mgrinich@gmail.com>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] Detecting HIGHESTMODSEQ changes/polling for
	flag changes
In-Reply-To: <4E9EBB0E-ADFB-4F79-A27B-51ADC8395D71@apple.com>
References: <4E9EBB0E-ADFB-4F79-A27B-51ADC8395D71@apple.com>
Message-ID: <CAO3aFYvtP0Xst5tpG_UOL_PL8e7k7NSONp-2VPsf7HksenwLmw@mail.gmail.com>

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/5ebf943f/attachment.html>
