I have been doing some testing with the recent support for IMAP IDLE (RFC 2177) or Push E-mail using IMAP.
It might surprise people but IDLE is currently supported by most IMAP servers. I tested with Cyrus, Exchange, Isode M-Box, Courier and Dovecot. The only one that didn’t worked with the current solution in tinymail was Dovecot. I did see the right EXISTS coming through, it seems that the UID FETCH that follows gets wrong information. I really haven’t in depth looked at this though. So I’m not yet blaming Dovecot for this. It might very well be a discrepancy in how I’m using IDLE.
ps. I’m tracking the testing of IMAP IDLE & Push E-mail here.
Actually nope. IDLE is really “basic” and I have been complaining about Evolutions lack of supporting it over 2-3 years now. All other clients I have used support notification (or push as you wanna call it) excluding Evolution/Camel.
Well, it’s not really simple to get it truly right. I suspect that most of those e-mail clients you tried periodically check for new messages. Which is not what IDLE is about. In case of IDLE, you get unsolicited EXISTS, RECENT and EXPUNGE information on which you have to act.
If you want to do all that with a single connection, it means that you need to start IDLE after your commands are finished, and DONE that before a new command starts. In between the two you’ll be handling this. In case of camel-lite it’s a non-blocking read that checks for new information (or no new information) on the socket.
Although that a pipelinging oriented design would work much better (it’s just an event like any other to handle).
Neither are simple. Looking at the quality of some of the other E-mail clients, I don’t think the developers of *ALL other clients that you have used* got this right.
But I’m sure that indeed some got it right. I wouldn’t call it *basic* though. There’s a lot to it that can go wrong. And what I have explained here only touches the IMAP part, not the ui and everything involved.
However. Feel free to port my camel-lite work to upstream Evolution’s Camel.
> In case of IDLE, you get unsolicited EXISTS, RECENT and
> EXPUNGE information on which you have to act.
This is true in ordinary IMAP as well. You can get those messages in response to any command. (Camel just wasn’t originally written to deal with that possibility, so it ignores them.)
Anyway, I use dovecot+IDLE (via ChatterEmail on the Treo) and it works fine, so I’m guessing you’ve got a bug. (Either that or ChatterEmail has a workaround I guess…)
PS – requiring logins to post comments is lame :)
I noticed that if I switch to using Maildir on the server, with Dovecot, that everything just works. So I will be looking at what I’m doing vs. what Dovecot returns me in case it uses Maildir and in case it uses its own “mail” folder in the $HOME.
This rarity however makes me believe that it’s not a bug in the client implementation. Also given that so far every other server seems to work just fine.
Who says that you have to have only one connection. Thunderbird e.g. uses one connection for IDLE and up to max_connection for anything else you do (IIRC). I also had to work with Outlook for the project I did a year ago and I am afraid to say it was really quick and always got all the changes I made right.
Evolution on on a different note is not really the client you wanna use together with other clients at the same time for a few reasons. E.g. it doesnt even update flag changes immediatly. (I know that this was a design desicion – which I don’t like at all).
Evolution has a different scope than the project for which I’m doing these changes (tinymail). Managing multiple connections over GPRS might definitely be doable, but it’s something I prefer to avoid rather than encourage.
So far I haven’t had any use for “max_connection for anything else”. That’s because the assumption in tinymail is that on a mobile device yuo ain’t going to do more than one thing at the same time, with your E-mail client.
IDLE can happen inbetween IMAP commands. It doesn’t have to be a new connection nor a thread. On a desktop MUA, however, you are probably right about this.
The changes that I’m making are, however, not about desktop MUAs.
So that you dislike that design decision about Evolution is something you’d better communicate with the Evolution Mailer developers :)