Re: [imap5] Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

On Fri, Feb 10, 2012 at 10:09:48AM -0500, Cyrus Daboo wrote:
> For CalDAV and CardDAV we (Apple, http://calendarserver.org) have
> used XMPP pubsub and our own APNS to implement a push notification
> service. Frankly I think the IETF should have developed a proper
> notification protocol for use alongside other protocols a long time
> ago - simply "blessing" XMPP pubsub as the solution for that would
> be fine from a standards point, but perhaps something else (new)
> coukld be done too. What then needs to be defined are the hooks in
> each underlying protocol to allow clients to discover the
> appropriate pubsub service. In CalDAV/CardDAV that is simply done
> using WebDAV properties to advertise the essential client push
> configuration.

I really should make sure we're compatible with what you're doing
too.  Obviously, there's a tradeoff between being able to do
everything in one protocol vs simplicity and saving the wheels
from being reinvented all over again.

I really appreciate your input here - you've got some good points,
and an actual implementation of something interesting, which trumps
talking every time!

> So, in my opinion, whilst push notifications should be a requirement
> for imap5, we should not define that protocol and instead push the
> IETF to provide such a protocol for general use.

My plan is to define in-band push if there's an active TCP connection,
plus out-of-band notifications.  Either way they would be of the
"something has changed, go request an update to the views you are
interested in"...

What we've done at mail.opera.com for a web-based system is to
use eventsource to push just a "here's a new modseq for you" to
the client, after which it can request a diff against the previous
view.  This works because we use a single HIGHESTMODSEQ counter
across all the users' mailboxes.

Obviously, it doesn't scale so nicely to shared folders.  For this
I'm seriously considering a CHANGEROOT or similar, which would be
a tree of related folders in which modseqs are serialised.  For a
64 bit counter, there's probably actually no real problem with
updating them across the entire server - other than then having to
filter the change notifications so you don't generate a zillion
spurious "something may have been updated" notification to every
client.

Bron.