MBOX-Line: From brong at fastmail.fm  Thu Mar 20 16:31:30 2014
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
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: <1395358290.2758.97026017.3C51C295@webmail.messagingengine.com>

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.

I should also probably detail what we do for FastMail's web interface here,
which uses EventSource to get notification of updates.

Our backend Cyrus servers have rfc5423 MessageEvents support, thanks to
ATOS WorldLine for adding the feature to Cyrus.  We've instrumented them
with tons of custom stuff for ourselves like pushing the envelope details
for new deliveries for nice little popup messages - but the main use is
that they tell the new highestmodseq for every folder.

In our case, we also use a single 'highestmodseq' counter per user, so that
you can quickly work out which folders changed, while only transferring a
single synchronisation status number.

The MessageEvents feed to a daemon on each IMAP server which also takes
registrations from the frontends when a web browser sets up a new
eventsource channel.  The channel is informed of the new highestmodseq,
and the browser makes an XMLHttpRequest to ask what actually changed in
the views it's interested in since the previous modseq.

(most of the XMLHttpRequest is documented at http://jmap.io/)

This allows a single number to represent that something has changed on
the server.  We never actually push the new state, just that there's
something to resynchronise - minimising the number of codepaths and
the opportunity for things to get out of sync.

Obviously, we'd love to integrate this with platform-specific notification
channels as well over time.  For now it's all purely within the browser.

Sadly, IDLE doesn't really do what anyone needs, because clients want to
know about changes to other folders - leading to every client having to
implement some form of what you're doing - either running STATUS on each
folder, or even just SELECTing each folder to check for changes.

Bron.

-- 
  Bron Gondwana
  brong@fastmail.fm

