I wanted to request IDLE-Support for IMAP since the new version of libEtPan supports it (see bug #22).
I don't like to poll every X minutes Y folders on server to check if a mail arrived. I like to see a real-time notify of a new mail in any folder (server-side filtering).
I often have claws-mail in background and my mail-checker (gnubiff with IDLE-Support) notifys a new mail in my INBOX. It would be nice if the mail is already in INBOX in claws-mail, too. Without to check the folders in claws again.
This is one of the very few things I lack in Claws.
+1 from me, too.
Is someone already working on this or is no developer interested in it?
From what I know, no developer's interested until now.
...the only missing feature that prevents me (and perhaps others somewhere out in space) from using claws.
-- Bugzilla database cleanup --
It looks like nobody has been interested in implementing this feature since the end of 2007; in order to clean up the bugzilla, I'm marking this WONTFIX.
Features in Claws Mail get implemented on a developer-interest basis: if one of the core developers codes a feature, or if an external contributor provides a good patch, the feature gets added. If the feature interests nobody with coding abilities, although it seems nicer to leave old requests lingering in Bugzilla and let the submitter hope the feature will be added someday, it's more honest (and cleaner) to close them as WONTFIX.
*** Bug 1748 has been marked as a duplicate of this bug. ***
i also would like the idle feature support :)
lets try to hook some developer to do this: a bounty
I will offer 30
(In reply to comment #7)
> I will offer 30
(In reply to comment #8)
> (In reply to comment #7)
> > I will offer 30
Why offer cash to a potentially one-time developer when there are several people who have given up extended periods of their life for this project?
Donations to the team are welcome, as long as they come with no strings attached, and are a thank you rather than a request.
A useful implementation of IDLE is more than 10 minutes, even using libetpan.
It seems that developers of claws mail have other priorities but you already know this.
Even with IDLE, the mail application will poll every 30 minutes.
For information IDLE is being deprecated by IMAP NOTIFY since IMAP IDLE is not sufficient.
I will consider it a loss of time to implement IMAP NOTIFY (but that's my own opinion).
(In reply to comment #9)
> I somewhat disagree. People need motivation. Money is a great motivator.
Yes, and that's why we go to work every day :)
But I doubt any amount of bounties or inducements would allow any of us to earn a living out of Claws, which means that if money replaces the fun, Claws Mail would essentially be dead.
Of course, those considerations worth for amounts below 100,000 bucks :-). I accept paypal payments, BTW.
Hello DINH Vi
>> Even with IDLE, the mail application will poll every 30 minutes.
> I don't understand, why should claws do this?
Because IMAP IDLE RFC tells to do this.
IMAP NOTIFY :
*** Bug 2772 has been marked as a duplicate of this bug. ***
I'd realy like to see claws-mail supporting IMAP-NOTIFY since most other mail clients with IMAP support already having this feature.
Seems worth undigging. If I could I would implement it.
> I wanted to request IDLE-Support for IMAP since the new version of libEtPan supports it (see bug #22).
> I don't like to poll every X minutes Y folders on server to check if a mail arrived. I like to see a real-time notify of a new mail in any folder (server-side filtering).
> I often have claws-mail in background and my mail-checker (gnubiff with IDLE-Support) notifys a new mail in my INBOX. It would be nice if the mail is already in INBOX in claws-mail, too. Without to check the folders in claws again
>This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from mailboxes.
> The extension allows clients to only receive events they are interested in
> For the new messages delivered to or appended to the selected mailbox, the NOTIFY command can be used to request that a set of attributes be sent to the client in an unsolicited FETCH response. This allows a client to be passive recipient of events and new mail, and be able to maintain full synchronisation without having to issue any subsequent commands except to modify the state of the mailbox on the server.
+1 @ Kardan's comment!
Adding this would help with a at least a couple of the current enchancement requests:
* "Check for new folders" on remote mailboxes is very slow http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2119
* "Implement Push IMAP"
A.F.A.I.K. IMAP feature called "IDLE" uses one tcp connection per folder. This can be the reason to not implement IDLE support in claws-mail because of many people use a lot of IMAP folders. But Thundebird for example has special settings for IDLE -- number of connections, and most people need only INBOX check for a new mail.
B.t.w there is another imap feature called "NOTIFY". It does not require one connection per folder and it uses one connection per all. This is a relatively new imap feature but it is already supported by dovecot (popular imap server) I have not tested it because I have no e-mail client that accurately supports this feature (or I do not know about it). May be implementation of NOTIFY is better then IDLE ? Although I would have been happy both :-).
Voting for "NOTIFY" feature as well. I knew it has been specified, but did miss that dovecot supports this.
Voicing my vote for NOTIFY support.
I'm missing IDLE support and using a biff like solution now, which runs a script to fetch on IDLE notifications. Native NOTIFY support would be welcomed.
*** Bug 3182 has been marked as a duplicate of this bug. ***
*** Bug 2212 has been marked as a duplicate of this bug. ***
*** Bug 3273 has been marked as a duplicate of this bug. ***
Any chance to reopen? NOTIFY would be great enhancement of claws-mail. Sylpheed has plugin for it on https://github.com/clehner/sylpheed-imap-notify.
Voting to reopen this request too, perhaps as a plugin?
I vote for reopening. I much prefer this method rather than checking every few moments.
This is not a voting platform. Votes don't mean anything. Code does.
(In reply to comment #29)
> I vote for reopening. I much prefer this method rather than checking every
> few moments.
I have been looking into this in the past but since claws is not using a threaded architecture it is not easy to do this. This reason for this is that IDLE needs a shared environment to prevent out of order protocol request/reply which is not possible with claws' current state of code. Out of order protocol request/reply will stop the communication flow until RSET is sent in which case the communication will have to start over again.
NOTIFY seems be technically possible so in the event of me having free time I might through in some time for this.
Last comment sound like WONTFIX because INCOMPATIBLE with claws.
comparison to other clients:
(In reply to comment #32)
> Last comment sound like WONTFIX because INCOMPATIBLE with claws.
Not really, it's implemented in the Sylpheed plugin which is also single threaded, from its README:
| The LibSylph IMAP4 client implementation is synchronous. When IMAP NOTIFY/IDLE
| is used, notifications could arrive at any time. This would require significant
| changes to LibSylph's IMAP code. This plugin uses a workaround of having a
| second IMAP session for the asynchronous events, so that the core IMAP code
| is left untouched.
The same could be done within Claws Mail.
My problem with this bug is that it contains two separate requests:
- IMAP IDLE support
- IMAP NOTIFY support
The first was deemed "wontfix" due to architectural reasons (comment#31).
The second was suggested as to be implementable in various ways (comment#31 and comment#33), citing even an existing LibSylph example.
The bug was closed as WONTFIX, despite that only IDLE was considered that and not NOTIFY, but all the NOTIFY related bugs were closed as DUPLICATE to this issue.
What shall happen to IMAP NOTIFY? (It's been supported by Dovecot for the last 10 years, for example.)
Shall bug#3182 be reopened instead as it's not a direct duplicate of this mixed issue?
The status still, ahem, /states/ where we are: patches are welcome.