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. _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
