Am 20.08.2013 01:45, schrieb Stan Hoeppner: > On 8/19/2013 4:10 PM, Reindl Harald wrote: > >> may i suggest you read about how IMAP IDLE works? > > Oh, well sure, if you hang your hat on IDLE then your arguments here > might make sense. But because of the brain dead one socket per folder > architecture of IDLE few have adopted it en masse. Which is why my > comments ignored the existence of IDLE. And which is also why the > creators of the RFC stated clients must not count on the existence of > IDLE and must poll, which seems really odd. Many have, and still ask, > why even have IDLE then if we must still poll? > > http://tools.ietf.org/html/rfc2177 > > "(While the spec actually does allow a server to push EXISTS responses > aysynchronously, a client can't expect this behaviour and must poll.)" > > Given the option of potentially dozens of open sockets between his > server and any client simply to allow IDLE to work for all folders, or > one or two connections and strictly client polling, I'd guess most > admins will choose the latter
why we have IDLE is easy explained, i get around 500 mails per day well, i can't imagine my personal work-load woking without IDLE 30 folders sorted with Sieve * several lists with own folders * company (there folders, one for internal lists) * customers * vendors * server-status (logwatch, mail-stats of 20 servers) * error-notifies from watchdog (own cron-watchdogs, HP ILO, VMware vSphere, UPS...) INBOX is a place where rarely a message comes in and with K9 on Android it's easy to select which folders should be considered for the common-inbox and which are pointless on a mobile (INBOX is none of them) on a mailserver which can handle thousands of connections there is rarely a reason to disable IDLE and so a connection limit of 10 per IP is questionable
signature.asc
Description: OpenPGP digital signature
