On Fri, 16 Dec 2005, Mark Sirota wrote:
While the mail_ping() loop is functionally identical to IDLE, it seems to me that the tradeoff is whether to put the resource burden on the client or the server, which may start mattering when we get into the several thousand mailbox level, depending on the scalability of the client and server architectures and the specifics of the IDLE implementation on the server.
I don't think that this is the correct view of the tradeoff, although it may be a factor in a server architecture in which email delivery causes event notification.
The usual reason for IDLE is to reduce network traffic. It also can help in the case of mobile clients by reducing battery consumption. This is a big issue, especially with IMAP-capable cell phones.
The flip side is that IDLE has proven disasterous if there is any sort of NAT or similar facility between client and server. The inactivity causes the NAT mapping to be purged, and then when the server does send something the session gets killed. NAT and similar facilities presume HTTP and such protocols in which activity is client initiated. Server-initiated activity, such as IDLE, is not accomodated at all.
As a consequence, some server implementations (such as UW imapd) end up sending an untagged OK every two minutes or so, with the sole purpose of causing a TCP ACK from the client and keeping the NAT mapping alive. The mobile device guys complain about this behavior (and have good reason to do so!) but no obvious solution has come up.
The upshot is that many people feel that IDLE was a good idea for its time, but not the right idea for modern needs; and that a separate "push" type notification mechanism is what's really needed for mobile devices.
As IMAP is fundamentally a "pull" type protocol, such notifications would be done by a mechanism outside of IMAP. This is actually not a bad thing; if all you want to do is light the little "voice mail" light on the phone, you don't really need to have an IMAP session monitoring the mailbox 24/7. You just need a notification from whatever agent *delivers* the voice mail, and perhaps also some mechanism in the IMAP server when all new voice mail has been read to turn the little light off. This will scale better, since then the IMAP session is only activated when the user requests it.
Are there any plans to implement IDLE in a future release of the c-client? If I ended up writing it myself, would you welcome the contribution?
I'll look at it, but I can't promise that I would adopt it. Nor can I promise that if I adopt it, that it wouldn't have a different interface.
c-client is fundamentally synchronous in its implementation of IMAP, and IDLE is very much asynchronous. It'll need careful consideration.
-- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
