[Kde-pim] Comments on the recent IDLE vs. NOTIFY thread

[Jan Kundrát]

Hi, sorry for bringing up an older thread, I was not subscribed to this list before today. (And I don't know of a way to fetch the old messages from mailman, hence a new thread. Sorry for that, too.) I have several comments to the discussion about IDLE and NOTIFY.

1) I am not aware of any released IMAP server which supports NOTIFY. Cyrus' master branch does not advertise that capability to their clients (cf. imap/imapd.c, the block starting at line 282 and the capa_response function on line 2952 as of commit a42a2fe848e6d7acfd9026e8fe5b0f41b159b052). Please keep in mind that there are many Google hits for "cyrus notify", but I suspect they must be referring to Cyrus' notifyd daemon, not to RFC 5465. Maybe the person assuring you about the NOTIFY support in Cyrus was confused by that as well?

The Dovecot's implementation was in early beta this summer when I was thinking whether to implement NOTIFY in Trojita. In the end, I decided to focus on other extensions at that time and revisit NOTIFY later on. Dovecot 2.2 has not been released yet.

2) Power concerns were raised. I do not believe that having twenty TCP sessions idling most of the time has power consumption impact worse than having a single TCP session hoping between mailboxes every few minutes, but I do not have any measurements to back my claim.

3) People were concerned to not overload the IMAP servers. My opinion is that actually having dozens of idling connections is better than keeping one of them busy all the time, doing the same work repeatedly, but this opinion is not shared by a typical system administrator who would indeed go berserk upon seeing "so many connections". A reasonable implementation of IDLE will therefore have to indeed limit the number of parallel sessions. This is complicated by the fact that the IMAP servers typically won't be polite to say "hey, please don't open so many connections", but will just close some of the connections without giving a machine-readable explanation, so this situation might be hard to detect by the MUA. Most MUAs that enable parallel IDLE put a limit on the number of parallel connections, and I agree that this is reasonable.

4) It was suggested to focus on ESEARCH, CONDSTORE and QRESYNC. I agree with this wholehartedly, each of these extensions brings up tremendous savings in the number of transferred data. (Provided that your IMAP server implementation offers these extensions. The sad truth is that these are rather scarce among non-FLOSS mail servers; GMail doesn't support any of these in particular -- but neither does it support NOTIFY.)

5) It was proposed to quickly switch among mailboxes with IDLE. I am afraid that this will not improve the situation at all; the whole point of IDLE is to make sure that a mailbox does not have to be reselected and resynchronized over and over again.

With kind regards,
Jan

-- 
Trojita, a fast Qt e-mail client -- http://trojita.flaska.net/
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/