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