what is the rfc for this? what is it useful for? etc etc etc

Many IMAP RFCs: http://www.networksorcery.com/enp/protocol/imap.htm

For IDLE: http://www.networksorcery.com/enp/rfc/rfc2177.txt

This extension allows to track the changes in IMAP mailboxes in
realtime (without explicit polling). Now, when courier-imap uses FAM
library for effective IDLE implementation - it would be so cute if
evolution will benefit from this fast notification chain: user would
see a message at the very moment it arrives to the server. Probably,
other IMAP servers can use FAM too (or plan to do it at some point).
The extension is very simple (only 2 commands).

I second this, the IDLE extension is an excellent idea, cleanly  
implemented and very useful. No Unix client (at lest not the GUI ones I've  
tried) seems to support it. Microsoft Outlook and Outlook Express are the  
only clients I have found that support it so far, rather ironic given that it is  
a worthy RFC!  
  
AFAIK, the vast majority of commercial mail servers (including MS  
Exchange) support it, and I recall someone saying that only one out of  
the major three open-source onces didn't (though sadly, I forget which  
one - I think that was on a similar bug filed against Mozilla).  
  
I use courier-imapd and it supports IDLE as long as it was compiled  
against a system with a correctly installed fam-oss. Some useful info (for  
users and developers alike) is available here:  
http://www.courier-mta.org/imapd.html  

It is nearly a year since this bug was filled. Any progress/plans?

no plans.  the current imap implementation is based on a
fully-synchronous api, which would make it basically impossible to
implement.

Any plans to make it async? Not official, but any thoughts on this
would be welcome. Now, I got the impression Evolution is totally not
interested in async IMAP support - which sucks.:( 

it would be nice to have, but we just haven't gotten around to
rewriting imap yet (well, we have sort of started rewriting it in our
spare time but progress is extremely slow)

Well, at least it gives some hope:) Count on me when you have
something to test.

http://blogs.msdn.com/omars/archive/2004/02/19/76061.aspx

According to this document, Thunderbird supports IDLE. So "no unix
client" is not true any more.

> According to this document, Thunderbird supports IDLE.

Not so I'm afraid. That assertion was erroneous (see the comments at
the bottom of that page). It isn't likely that Thunderbird would
support any major architectural change at this point without it being
manifested in Mozilla Mail first! Here's the link for the relevant
entry in Mozilla's bugzilla:
http://bugzilla.mozilla.org/show_bug.cgi?id=141369

Right. It seems the guy used incorrect info. So - the more honour
would be for Evolution to support IDLE before Thunderbird!:)))

Hi Evolution People,

I've written an IMAP server, and it supports asynchronous
notification of new messages.  But I can't find any clients to use
it with!  I hope this gets implemented one day, as Evolution is
generally a great piece of work.

For your information: the IMAP IDLE extension is not necessary for
asynchronous notification.  *Any* IMAP server can deliver
"unilateral" untagged data to clients at any time.  Quote from
RFC2060 (IMAP) intro to section 7:

"An example of unilateral untagged server data occurs when the IMAP
connection is in selected state.  In selected state, the server
checks the mailbox for new messages as part of command execution.
Normally, this is part of the execution of every command; hence, a
NOOP command suffices to check for new messages.  If new messages are
found, the server sends untagged EXISTS and RECENT responses
reflecting the new size of the mailbox.  Server implementations that
offer multiple simultaneous access to the same mailbox SHOULD also
send appropriate unilateral untagged FETCH and EXPUNGE responses if
another agent changes the state of any message flags or expunges any
messages."

The point of the IDLE extension is that normally a client doesn't
know whether the server is going to send it "unilateral" updates
or not; if the server isn't going to send them, it has to poll
by sending periodic NOOPs.  If the server advertises that it
supports IDLE, then the client can send an IDLE command and know
for certain that it will get updates.  

(BTW, I take it from all this that Evolution will get confused if
another client is accessing the same mailbox and changing its state?)

Regards,

--Phil.

I've been working on a new IMAP client implementation but it will not
support IDLE. This is mostly because the IDLE extension does not fit
in well with the overall design of Camel.

to see what I've got so far, take a look at:

evolution/camel/providers/imap4/

(evolution/camel/providers/imap/ is the current implementation which
is known to be less than ideal, to put it nicely)

my new design/implementation *does* handle untagged events correctly,
and so does not suffer from the problems of the current implementation.

My new implementation will continue to use the NOOP command to give
the server a chance to notify us about updates.

I personally think that the IDLE command is overhyped. As long as the
client is requesting information from the server (which is generally
the case anyway), we get updates. If not, then the user must not
currently be reading mail - and if that is the case, then we'll still
get updates every time the auto-send&receive timeout expires and/or
the NOOP timeout expires.

Thanks for the new IMAP implementation -- it comes as a welcome
relief.  However, I would respectfully disagree with the assessment
that IDLE is overhyped.  How often has this happened to you:  You ask
for something from a nearby co-worker, and they tell you "I just sent
you an email".  At that point you repeatedly click "send/receive"
expecting the message.  It doesn't come due to delays on the
server....so you keep clicking.  Maybe I'm just obsessive-compulsive,
but if Evolution supported IDLE, I would know that I would never have
to do that -- I would be notified instantly when the message finally
arrived.  Repeatedly clicking send/receive stresses both the IMAP
server's load and my patience.

I can sympathize with the fact that the camel architecture doesn't
allow the IMAP file descriptor to be monitored by the main loop.  I've
been in that situation before too -- when a seemingly trivial feature
is extremely non-trivial to code due to prior design choices. 
However, although such a situation may cause the feature to be
delayed, it should never cause it to be dismissed or its usefulness
disputed.  I really hope there is some way that things can be
re-architected to allow the IDLE extension.  It's a useful feature to
many people and it's one of those things which makes the product seem
much more solid and responsive even if some users don't even realize
it's there.

as zucchi just reminded me, we could put the CamelIMAP4Engine (or
whatever) into another thread and have it emit notifications that way
(since the front-end code will properly proxy them off to the main
thread for gui updating).

so this is just harder...

Camel can easily support IDLE, the fact its API entry points are all
synchronous is irrelevent (actually it probably helps).

The problem is that in the *current* IMAP implementation, all server
interactions are synchronous, and driven directly by the API.  But
there's nothing to stop an implementation having a dedicated
imap-connection servicing thread which can receive asynchronous
notifications using its own main loop.  Camel's notification mechamism
is already asynchronous, so all you need is a servicing thread, some
message queues, and thats about it.

So simply put, this is still "future", if we didn't think we could
ever do it (and to me that would be a severe architectual
shortcoming), it would've been closed ages ago.  The imap
implementation i was working on in my spare time wasn't going to do
IDLE, but it could have been added.  The code itself is a long way
from working though.

So, I guess for now, users are just going to have to exercise their
finger a little more.

Count me in as another use very interested in getting IDLE support
Evolution.

I've been using a IDLE enabled IMAP client on another platform and
I've gotten very addicted to the 'IDLE' way of life.

Yes I'll second, third and fourth the calls for IDLE support. We use
Thunderbird exclusively in our Linux call-centre mainly because it's
the only capable Free Software client that supports IDLE. When you
have 30 people sharing the same sets of 'Service' IMAP mailboxes, IDLE
is about the only way you can stop customers from getting double or
triple responses!

The KDE devels have already told me that IDLE isn't coming any time
soon in KMail because the entire KIOSlave architecture can simply not
support any server-driven input at this time... it all has to be
client-invoked :/

From what I read, Evolution is the same? 

It's months since this bug's had any activity - is there any progress
on this? I would certainly never advocate any client that didn't
support IDLE thesedays. It's definately *not* overhyped.

Cheers,
Gavin.

no progress... it's non-trivial and like I said way above, overhyped.

if you are interested in implementing it tho, go right on ahead. we
have been known to accept patches :)

Any progress? I fully support the requests for IDLE ext. support, is major
drawback for evolution.

I've left the project and Michael is about to leave. No progress has been made
afaik.

The good news is a bunch of fresh blood has taken over the project in India and
they all seem full of energy, so maybe this will happen faster now :)

I also support the request for this IMAP enhancement. I don't want to use 
Thunderbird anymore. :(

No acitivity on this bug since 2005? Well, I better get on CC:. IDLE support would be really neat.

Have you considered putting it up as a Summer of Code project?

I'd certainly be ok if someone wanted to do it as an SoC project, but I doubt it'd get finished... just seems a bit hard to do for an SoC project.

*** Bug 392333 has been marked as a duplicate of this bug. ***

*** Bug 434571 has been marked as a duplicate of this bug. ***

*** Bug 552224 has been marked as a duplicate of this bug. ***

Also see http://www.mail-archive.com/evolution-list@gnome.org/msg10773.html and so...

Volunteers willing to port welcome.

So what is the status of the port? This is pretty basic functionality that quite frankly should have been implemented long ago.

After so many years IDLE extension is still not implemented??? Can't get off Thunderbird without this one, since I work in tech support and sometimes even 1 minute for automatic mail checking of 4 accounts, is to long.

http://en.wikipedia.org/wiki/Push-IMAP

Sure would be nice to see Evolution in that list.

IMAP IDLE has existed for over 11 years ... That's really embarassing for the Evolution client.

Any chance we see this in 2.30?

Ah, I spent many hours to find out why I can't use imap-push, while everything was correctly configured, I was sure evolution managed it.
I hope it will be implemented in next version.

I vote for this.

*** Bug 605376 has been marked as a duplicate of this bug. ***

Can we expect this in 2.30?

+1 . This is must-have feature ! Very expected features from a profesional point of view. Get the message when it arrives ... and not 10 minutes later.

I just tested it in thunderbird + cyrus-imap, and this is just too great. I also really enjoy the little popup for mail notification, by the way.
Furthermore you have the same behaviour on Outlook.

Any progress on this bug?
Would like to see this feature in evolution

(In reply to comment #35)
> I vote for this.

+1

Folks, it is not necessary to "vote" for this to be implemented (as this bug is already set to NEW). If you want to make development of this happen, consider spending some time, money or both to actually help the project. Writing "+1" just wastes everybody's time. Admittedly, we do not have a good "code for money" program, but http://www.gnome.org/friends/ exists and I'd like you to visit that page before you ask whether this feature will be implemented.
Also, please consider using the mailing lists to discuss issues not directly related with the status of this bug.
Thanks

unfortunately GNOME bugzilla does not have a voting mechanism or affects me too like launchpad has.

so for developers to know which bug people are really wanting to be fixed there is no way except writing +1.

you should file a bug request for this feature if this annoys you much.

and i do agree having such a option would indeed be better.

Seriously, this is open since 8 years. Is anyone at least claiming to work on it?

Besides, couldn't you just copy the code from another open source client like Thunderbird?

(In reply to comment #43)
> Seriously, this is open since 8 years. Is anyone at least claiming to work on
> it?

Try imapx in Evo. It has IDLE support. This bug should be closed, actually.

Oh, thanks for this fine info. Searching for it didn't show me imapx...

So hopefully this helps further searchers to find imapx if they ever search for a ubuntu gnome evolution imap idle support plugin, addon or upgrade. :p


As far as I see it, to use imapx you have to install evolution 2.30?

(In reply to comment #46)
 
> As far as I see it, to use imapx you have to install evolution 2.30?

Check:

http://chenthill.wordpress.com/2010/01/11/evolution-with-improved-imap-support-imapx/

IMAP+ backend supports IDLE, closing as obsolete.

Not too sure having separate IMAP and IMAP+ backends is a good idea, but that's for another bug. I hope IMAP+ eventually replaces the IMAP backend.