Re: [Imap-protocol] Detecting HIGHESTMODSEQ changes/polling for flag changes
Ian Anderson <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 <[email protected]> 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 > [email protected] > http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol _______________________________________________ Imap-protocol mailing list [email protected] http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol