[Dovecot] blackberry with imap idle and concurrent connections

Bill Cole dovecot-20061108 at billmail.scconsult.com
Wed Sep 26 17:41:08 EEST 2007


At 8:16 AM -0600 9/26/07, Chris Tirpak wrote:
>>  I have just confirmed with a direct test that Dovecot 1.0.0 using
>>  Maildir does properly service 2 simultaneous IDLE sessions on the
>>  INBOX. I've got my Palm ChatterEmail client logged in and idling and
>>  have a manual IMAP session (telnet localhost 143...) and the messages
>>  are popping up on the Palm in lockstep with the 'EXISTS' messages
>>  kicking out on the telnet session. Meanwhile, Eudora is doing its
>>  things from my Mac against the same mailbox (actually tossing
>>  messages out of INBOX to other folders) and I'm pretty sure I left
>>  Outlook running on my office machine and looking at the same mailbox,
>>  so whatever flaky stuff it does is happening on whatever schedule it
>>  uses as well...
>
>Thanks. I have been using the same setup as you with no problems on my
>existing server and loved it but have to say that the future of
>Chatter looks questionable and my BB's get much better voice and
>battery.

I saw the purchase of Chatter by Palm early this year as a positive 
sign. After all, VersaMail is such a piece of junk and they really 
needed something to answer Blackberry and the Windows Mobile push 
approach.

As for battery life, I can attest to my Treo 650 running an IDLE 
session being only a semi-portable device, particularly if I have the 
BT radio on as well. I don't know how well the Blackberries do, but 
it doesn't surprise me that they do better. I also can't recommend 
that anyone with metered data usage use the Chatter IDLE route, since 
that means a full-time data connection.


>>  Note that one strong consideration for IMAP servers with more than a
>>  handful of users is going to be dealing with the high concurrency of
>>  a lot of eternal connections from the Blackberry server and from
>>  other clients latched onto the same mailboxes. I suspect that one
>>  reason some systems limit concurrent sessions  is that they don't
>>  have (or haven't be configured to use) efficient filesystem event
>>  monitoring, and the alternatives are quite burdensome. In the case of
>>  Courier, it looks like it still relies on SGI's FAM, an abandoned
>>  project that doesn't really work well anywhere but Irix and Linux.
>>  Dovecot has avoided that at the cost of having to understand each
>>  system's unique approach to that issue.
>>
>
>Thanks for the insight.

-- 
Bill Cole
bill at scconsult.com



More information about the dovecot mailing list