Bug 1408 - IDLE-Support with libEtPan (since 0.52)
Summary: IDLE-Support with libEtPan (since 0.52)
Status: RESOLVED PATCHESWELCOME
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Folders/IMAP (show other bugs)
Version: 3.1.0
Hardware: All All
: P3 enhancement
Assignee: users
URL: http://www.rfc-archive.org/getrfc.php...
: 1748 2212 2772 3182 3273 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-27 13:20 UTC by A. Klitzing
Modified: 2022-11-20 11:19 UTC (History)
19 users (show)

See Also:


Attachments

Description A. Klitzing 2007-11-27 13:20:13 UTC
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.

Thanks!
Andr
Comment 1 Pierre Ossman 2008-01-08 08:49:36 UTC
+1

This is one of the very few things I lack in Claws.
Comment 2 Stephan 2008-02-06 14:49:40 UTC
+1 from me, too.

Is someone already working on this or is no developer interested in it?
Comment 3 Colin Leroy 2008-02-06 14:56:53 UTC
From what I know, no developer's interested until now.
Comment 4 Andr 2008-02-25 08:08:00 UTC
+1

...the only missing feature that prevents me (and perhaps others somewhere out in space) from using claws.
Comment 5 Colin Leroy 2008-07-05 13:52:42 UTC
-- Bugzilla database cleanup --
Hi, 
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.
Comment 6 Colin Leroy 2008-10-06 18:09:08 UTC
*** Bug 1748 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Mota Leite 2008-10-07 00:36:07 UTC
i also would like the idle feature support :)

lets try to hook some developer to do this: a bounty

I will offer 30
Comment 8 Colin Leroy 2008-10-07 11:31:46 UTC
(In reply to comment #7)

> I will offer 30
Comment 9 Gerard Seibert 2008-10-07 12:14:39 UTC
(In reply to comment #8)
> (In reply to comment #7)
> 
> > I will offer 30
Comment 10 Paul 2008-10-07 12:17:41 UTC
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.
Comment 11 DINH Vi 2008-10-07 12:21:27 UTC
Hello,

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).

Regards,
Comment 12 Colin Leroy 2008-10-07 12:22:17 UTC
(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.
Comment 13 wwp 2008-10-07 12:39:13 UTC
Of course, those considerations worth for amounts below 100,000 bucks :-). I accept paypal payments, BTW.
Comment 14 Maurice Meeden 2008-10-07 13:11:45 UTC
Hello DINH Vi
Comment 15 DINH Vi 2008-10-07 14:40:48 UTC
>> 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 :

http://tools.ietf.org/html/draft-ietf-lemonade-imap-notify-07

Comment 16 Paul 2012-12-15 09:14:13 UTC
*** Bug 2772 has been marked as a duplicate of this bug. ***
Comment 17 Heiko Adams 2013-06-24 16:00:47 UTC
I'd realy like to see claws-mail supporting IMAP-NOTIFY since most other mail clients with IMAP support already having this feature.
Comment 18 kardan 2013-07-08 14:15:58 UTC
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

http://tools.ietf.org/html/rfc5465
>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.
Comment 19 jdalinux 2013-07-08 15:50:53 UTC
+1 @ Kardan's comment!
Comment 20 Pranesh Prakash 2014-01-06 22:01:18 UTC
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"
http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2212
Comment 21 Anton 2014-01-07 08:26:10 UTC
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 :-).
Comment 22 Christian Hesse 2014-01-07 08:33:16 UTC
Voting for "NOTIFY" feature as well. I knew it has been specified, but did miss that dovecot supports this.
Comment 23 Marcel van der Boom 2014-01-07 10:21:50 UTC
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.
Comment 24 Paul 2014-05-25 20:20:56 UTC
*** Bug 3182 has been marked as a duplicate of this bug. ***
Comment 25 Paul 2014-09-05 16:58:54 UTC
*** Bug 2212 has been marked as a duplicate of this bug. ***
Comment 26 Paul 2014-09-05 16:59:03 UTC
*** Bug 3273 has been marked as a duplicate of this bug. ***
Comment 27 jackcooper 2015-08-20 07:19:29 UTC
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.
Comment 28 Marcel 2016-02-10 11:27:12 UTC
Voting to reopen this request too, perhaps as a plugin?
Comment 29 Larry J 2016-07-26 12:18:05 UTC
I vote for reopening.  I much prefer this method rather than checking every few moments.
Comment 30 Andrej Kacian 2016-07-26 12:39:59 UTC
This is not a voting platform. Votes don't mean anything. Code does.
Comment 31 Michael Rasmussen 2016-07-26 12:55:16 UTC
(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.
Comment 32 kardan 2017-12-20 00:25:38 UTC
Last comment sound like WONTFIX because INCOMPATIBLE with claws.

comparison to other clients:
https://github.com/riseupnet/riseup_help/issues/465
Comment 33 Ricardo Mones 2017-12-20 13:04:02 UTC
(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.
Comment 34 Peter Gervai 2022-09-28 10:57:32 UTC
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?
Comment 35 Paul 2022-09-28 11:16:13 UTC
The status still, ahem, /states/ where we are: patches are welcome.

Note You need to log in before you can comment on or make changes to this bug.