Re: [Imap-protocol] Detecting HIGHESTMODSEQ changes/polling for flag changes

On Fri, Mar 21, 2014, at 05:32 AM, Ian Anderson 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.

This is pretty much the major reason that IMAP5 would be a good idea if
we can get enough consensus.  "IMAP" is such a large collection of
partially implemented standards now that it's very hard for client
authors to use any of the more advanced features, because they need to
write fallback support anyway - and then you either have two different
codepaths with different bugs and subtleties, or you throw your hands up
in the air and just support the most generic.  At least that works
everywhere.

> 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.

Since we control both our server and client, we use rfc5819 to get status
and mailbox listing information for all mailboxes in a single backend
request.  It's pretty fast because we have an on-server statuscache
database which stores the status information for every mailbox, and gets
either updated or invalidated by anything which writes to the mailbox.

It seems that pretty much everyone ignores the "SHOULD NOT".  It's a
wart.  It's pretty clear what STATUS is asking for.

I'm not sure what Timo's ImapTest does if you return an error for STATUS
on the selected mailbox, but it certainly complains if you return
inconsistent data (which is good).

STATUS on a selected folder would have been trivial in Cyrus except that
you can ask for RECENT in STATUS, and RECENT is bloody session specific,
so you can't just read from the statuscache or the mailbox files on
disk, you need to special case and introspect the index structure.

RECENT is a particularly nasty wart.

> 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.

Anyway, all the major open source servers (by which I particularly claim
Dovecot and Cyrus - they seem to be the bulk of sites these days) and
Gmail are very happy with STATUS on the selected mailbox.

Bron.

-- 
  Bron Gondwana
  [email protected]
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol