Comment 1 Andre Klapper 2008-11-23 17:41:35 UTC

> Add an IMAP account with a server that supports IMAP-IDLE.

That's vague and makes it hard to reproduce. Which exact server and version is
this?

> /var/log/mail.log

Is that on the server?

Which hardware is this about? N800, N810?

You do run 4.2008.36-5, right?

(In reply to comment #1)
> > Add an IMAP account with a server that supports IMAP-IDLE.
> 
> That's vague and makes it hard to reproduce. Which exact server and version is
> this?
Dovecot, 1.0.13

> 
> > /var/log/mail.log
> 
> Is that on the server?
Yes
> 
> Which hardware is this about? N800, N810?
N800
> 
> You do run 4.2008.36-5, right?
> 
Yes

Comment 3 Andre Klapper 2008-11-24 00:11:46 UTC

Can I get a log attached (please remove any confidential information first)?

Should work(TM) according to
http://pvanhoof.be/blog/index.php/2007/02/07/and-then-there-was-push-e-mail-support-for-tinymail-imap-idle

Actually, it seeos to be my bad! The LED notification is flashing, but I didn't
notice, and there's no on screen notification (New mail symbol).

Marking as a duplicate of #3689, if that's appropriate.

*** This bug has been marked as a duplicate of bug 3689 ***

IDLE does not appear to be used again in 1.2009.41-10.

Steps to reproduce:

1. Configure modest with an IMAP account on a server that supports IDLE (using
dovecot 1.2 here).
2. Disable automatic mail check.
3. Start modest from an xterm or ssh session with "CAMEL_DEBUG=all
/usr/bin/modest -s".
4. Open account.
5. Open INBOX.
6. Send messages to that account.
7. Watch modest's output on the terminal and the INBOX view.

Outcome:
Modest never notices the new messages arriving in INBOX.  Terminal output
doesn't show an IDLE command issued, even though it's advertised in the
server's CAPABILITY response.

I don't think it's specific to any particular server.  Reproduced also with
cyrus imapd.

Comment 7 Andre Klapper 2009-10-30 12:48:19 UTC

Internal comment: "IMAP IDLE was disabled for power management reasons."

(In reply to comment #7)
> Internal comment: "IMAP IDLE was disabled for power management reasons."

Hm, déjà vu... (bug 3689 comment 35).  This time it's
<http://tinymail.org/trac/tinymail/changeset/3984> and
<http://tinymail.org/trac/tinymail/changeset/3993>, with more explanation
provided in
<http://mail.gnome.org/archives/tinymail-devel-list/2009-September/msg00003.html>:

> This is because the current implementation (based on a busyloop) is
> really expensive for power management.

Bumping back to normal severity, since the proper solution for this is to fix
tinymail's IDLE so it doesn't cause power management issues.  Normally IDLE
should be more battery-friendly than polling.

Comment 9 Andre Klapper 2009-10-30 18:42:08 UTC

So this is currently not planned for Maemo5.
For Maemo6 it's too early to say...

(In reply to comment #9)
> So this is currently not planned for Maemo5.
> For Maemo6 it's too early to say...

Somehow I don't see modest being rewritten in C++/Qt, might as well close this
as WONTFIX :-(

(In reply to comment #9)
> So this is currently not planned for Maemo5.
> For Maemo6 it's too early to say...

So we get "Fixed in Harmattan (maybe)" before Fremantle is even released?

Aw, come on.

A feature request is not the same as a bug.

(In reply to comment #12)
> A feature request is not the same as a bug. 

Well, obviously :-)

If you are you saying that IMAP IDLE support in modest is not a bug, I
respectfully have to disagree.  Bug 403 (for the original osso-email client)
may be considered an enhancement request, but modest was supposed to fill that
gap (original announcement:
<http://lists.maemo.org/pipermail//maemo-users/2007-December/008045.html>).

Indeed, modest did have IDLE support for several releases after that but it was
disabled at the last minute in the last Diablo SSU.  Then it was working again
in the pre-release Fremantle versions (trust me, I was building and testing
from git on a pretty much weekly basis) but pulled again right before release. 
Granted, there may have been valid reasons in both cases, but those are bugs in
themselves that should be fixed.

Not that I'm holding my breath mind you, but if it's not going to be fixed I'd
appreciate an honest WONTFIX resolution rather than turning this into
"enhancement" which I think is too much of a retcon/copout.

Comment 14 Andre Klapper 2009-11-09 10:48:08 UTC

I think that comment 12 "just" refered to comment 11 and the resolution
guidelines at http://wiki.maemo.org/Bugsquad#Resolution_guidelines .
Hence nobody called this here a feature request (yet). :-P

wait.. for power saving idle is turned off?
Why not let us as a user decide that what we want?

I use currently ProfiMail on my E90 and i have idle on all the time and that
doenst really affect my battery. I can use the E90 for 2 days like this.

So for me to get a sort of push back i have to poll about every minute.. And i
can place a bet now that then the battery will be drained.. because it has to
do way more stuff!

IMap-idle should just be blocking io for the most time (seen from the N900) and
that doesnt cost any cpu power.. Yes the wifi or 3g connection has to stay on
but on the N900 thats i think the whole point (being connected all the time)

Nokia Messaging is available in release build of Modest and it supports push
e-mail notifications. So it obviously does not have the power management issue?
How does it solve the problem? Maybe we could replicate the solution for IMAP
IDLE?

I was told so, but if i try to set up a "nokia messaging" account it actually
ends up with generic imap and polling.

(In reply to comment #16)
> Nokia Messaging is available in release build of Modest and it supports push
> e-mail notifications. So it obviously does not have the power management issue?
> How does it solve the problem? Maybe we could replicate the solution for IMAP
> IDLE?
>

(In reply to comment #16)
> Nokia Messaging is available in release build of Modest and it supports push
> e-mail notifications. So it obviously does not have the power management issue?
> How does it solve the problem? Maybe we could replicate the solution for IMAP
> IDLE?


The same for MfE but they are using different framework.  The problem is on
tinymail side, according to comments in internal bugzilla.

(In reply to comment #17)
> I was told so, but if i try to set up a "nokia messaging" account it actually
> ends up with generic imap and polling.

:-)  It basically means that Nokia Messaging does not work for you.  This is a
separate service and it uses separate protocol.

Looks funny, i just had to set up different region. There is a bug anyways: i
should be provided with some meaningful diagnostics, not just silently
redirected to imap account setup.

(In reply to comment #19)
> (In reply to comment #17)
> > I was told so, but if i try to set up a "nokia messaging" account it actually
> > ends up with generic imap and polling.
> 
> :-)  It basically means that Nokia Messaging does not work for you.  This is a
> separate service and it uses separate protocol.
>

(In reply to comment #20)
> Looks funny, i just had to set up different region. There is a bug anyways: i
> should be provided with some meaningful diagnostics, not just silently
> redirected to imap account setup.

Probably should be filed as a separate bug.

Comment 22 Neil MacLeod 2009-12-15 23:51:38 UTC

(In reply to comment #21)
> (In reply to comment #20)
> > Looks funny, i just had to set up different region. There is a bug anyways: i
> > should be provided with some meaningful diagnostics, not just silently
> > redirected to imap account setup.
> 
> Probably should be filed as a separate bug.
> 

Could be bug 6955.

still the priority is low for this bug now already 91 votes and counting?
For a device that nokia is advocating as the Internet device (not a phone) the
whole email side of it is not that good (and thats an understatement)

Can somebody not fork modest (as far as i know this one is open source right?)
and add it to extra's? So that we can install it besides the build in one that
only updates with a firmware update? So that the community can take care of
creating the best email client?

(In reply to comment #23)

> Can somebody not fork modest (as far as i know this one is open source right?)
> and add it to extra's? So that we can install it besides the build in one that
> only updates with a firmware update? So that the community can take care of
> creating the best email client?

It is free software[1] so you can fork it. I would suggest trying to submit
your patch fixing the problem here first/as well, though - why not contribute
your improvements back "upstream", as it were?

Best regards,
Adam

[1]
https://git.maemo.org/projects/modest/?p=modest;a=blob;f=COPYING;h=f5675225d7ff731bfb00de1573172079f1e8dc47;hb=HEAD

I'm perfectly aware that you don't appreciate bugspam, so instead of just
saying "me too"; I wonder if this:

http://dovecot.org/list/dovecot/2009-April/038607.html

could be part of the problem? On a couple of other phones I've had (that
supports IMAP IDLE), the battery lasted just some hours when the 'OK Still
Here' message came every 2 minutes. When I changed that timeout to 60 minutes
in Dovecot, the battery lasted for days.

Could this be related? If Dovecot was used for testing, for instance...

(In reply to comment #25)
> I'm perfectly aware that you don't appreciate bugspam, so instead of just
> saying "me too"; I wonder if this:
> 
> http://dovecot.org/list/dovecot/2009-April/038607.html
> 
> could be part of the problem? On a couple of other phones I've had (that
> supports IMAP IDLE), the battery lasted just some hours when the 'OK Still
> Here' message came every 2 minutes. When I changed that timeout to 60 minutes
> in Dovecot, the battery lasted for days.
> 
> Could this be related? If Dovecot was used for testing, for instance...
> 

Yes. Good addition. I would have thought that was pretty well known? Even IMAP
servers I've used that aren't mine don't send every 2-minutes so your point on
testing is good - perhaps threw something together? Other devices I've had with
IDLE support haven't caused me any noticeable battery problems. That's why I
was surprised on the reasoning listed and the apparent 'trade-off' (i.e. fetch
often).

I think someone else made a point to provide the user a choice on using IDLE
(push) or just fetch rather than making if for them. Give the user an option
that could easily be appended with "(May reduce battery life)" or whatever
wordsmithing.

People love options on their gadgets and puters - several have learned that
lesson over time and some have learned that lesson the not-so-good way and
changed.

(In reply to comment #7)
> Internal comment: "IMAP IDLE was disabled for power management reasons."
> 

I've had a look at current tinymail IDLE implementation and the only thing I
see there that might raise issues is a sleep loop instead of a proper select.
But that's trivial to fix so I'm guessing there's something else. 
Can you shed some light on this or should we try to guess from the #ifdef about
idle in the modest code ?

(In reply to comment #27)

> Can you shed some light on this or should we try to guess from the #ifdef about
> idle in the modest code ? 

Check this link, pls:

http://mail.gnome.org/archives/tinymail-devel-list/2009-September/msg00003.html

(In reply to comment #28)

> 
> Check this link, pls:
> 
> http://mail.gnome.org/archives/tinymail-devel-list/2009-September/msg00003.html
> 

Interesting. Unless I'm missing some snafu about select and idle threads that
patch seems more complex than the change required to fix the busyloop.
I'd say the fix is just changing camel-imap-folder.c:4236 to a proper select().
Any comment ?

(having said that, we'd need to fix the whole store->idle_sleep in ticks mess
too)

I've analyzed the code and it cannot be repaired that easily. There are more
conditions for the loop to execute than simply receiving data from socket.
Other threads may force the idle thread to exit immediately, so select() with
28m timeout will not do. 

The only workaround I can imagine is creating pipe in main thread and then
feeding it to select() in the idle thread. I'm not sure if it can be done this
way...

(In reply to comment #31)

> The only workaround I can imagine is creating pipe in main thread and then
> feeding it to select() in the idle thread. I'm not sure if it can be done this
> way...

Yes. Using a pipe is a common way to handle such situations. Works in
Unix/Linux, but not in Windows, afaik.

Anyone has noticed tinymail 1.0 has just been released to the wild? Looking at
the Changelog (
http://mail.gnome.org/archives/tinymail-devel-list/2010-March/msg00002.html ) I
can see some interesting things:

* Complete rework of IMAP IDLE locking

* Complete rework of the lock behavior of Tinymail IMAP IDLE implementation.
* New configure option --disable-idle, to disable IDLE
* Fix the IDLE delay account parameter to take into account the tick time.

Seems there has been some movement here. Maybe IMAP IDLE is coming to an N900
near you...

(In reply to comment #33)
> Anyone has noticed tinymail 1.0 has just been released to the wild? Looking at
> the Changelog (
> http://mail.gnome.org/archives/tinymail-devel-list/2010-March/msg00002.html ) I
> can see some interesting things:
> 
> * Complete rework of IMAP IDLE locking
> 
>

Cursory inspection shows STOP_IDLE_LOOP_WAIT is still there. I read that as the
interthread idle lock that was used to signal when to idle/unidle a mailbox was
redone in some other way. 
May prove useful to someone doing the select patch but doesn't seem to solve
anything directly.

A few years ago a patch was made that did exactly this. We didn't put it in a
release because it wasn't sufficiently tested.

Perhaps revive this and learn?

http://mail.gnome.org/archives/tinymail-devel-list/2007-October/msg00043.html
http://mail.gnome.org/archives/tinymail-devel-list/2007-October/msg00040.html

I'm still rocking my N810 and am in desperate need of the imap idle.  Can
someone please further the cause.  I am more than willing to trade the battery
for functionality.  Give me a choice :)

This bug is now referenced in a new brainstorm entry "Bridge the gap between
Modest and competing smartphone email clients", found here:
http://maemo.org/community/brainstorm/view/turn_modest_into_a_useable_email_client
. If you care about this bug, please vote for and contribute to the Brainstorm.

Comment 38 Andre Klapper 2010-12-16 19:18:30 UTC

This issue has been FIXED for Harmattan (the software version after Maemo5).

(In reply to comment #38)
> This issue has been FIXED for Harmattan (the software version after Maemo5).

That's cool but... what are we to expect? A backport? Will we be able to
install Harmattan on our device?

If not, I hardly consider this bug as "RESOLVED FIXED"

Regards

Comment 40 Andre Klapper 2010-12-16 19:24:58 UTC

(In reply to comment #39)
> That's cool but... what are we to expect? A backport? Will we be able to
> install Harmattan on our device?

Please ask Nokia via Nokia Customer Care, or in talk.maemo.org. Thanks.

(In reply to comment #39)
> That's cool but... what are we to expect? A backport? Will we be able to
> install Harmattan on our device?

It's Nokia - you have to get used to it. It is like when you report bug against
one Linux distribution and they will close it as RESOLVED FIXED due to bug
being fixed in other distribution.

(In reply to comment #41)
> (In reply to comment #39)
> > That's cool but... what are we to expect? A backport? Will we be able to
> > install Harmattan on our device?
> 
> It's Nokia - you have to get used to it. It is like when you report bug against
> one Linux distribution and they will close it as RESOLVED FIXED due to bug
> being fixed in other distribution.

It works the same everywhere. You report a bug on Fedora 13, and it would be
marked as fixed even if it's only coming to Fedora 14.

> > It's Nokia - you have to get used to it. It is like when you report bug against
> > one Linux distribution and they will close it as RESOLVED FIXED due to bug
> > being fixed in other distribution.
> 
> It works the same everywhere. You report a bug on Fedora 13, and it would be
> marked as fixed even if it's only coming to Fedora 14.

It's not the same at all. You don't have to buy a new computer to use the next
Fedora.

Please stop abusing bugzilla for complaining about procedures. If you think
those procedures are a bug, then open a new bug. You're devaluating this bug by
going off topic.

(In reply to comment #44)
> Please stop abusing bugzilla for complaining about procedures. If you think
> those procedures are a bug, then open a new bug. You're devaluating this bug by
> going off topic.

Is the problem resolved in a software version that can be installed on the
device where the problem was reported? If yes, then it's resolved. If no, then
it's not resolved. There's nothing procedural about it, this is a discussion
about if the status has been correctly set for a particular bug report, and
entirely within the scope of a bug report, and is how bug trackers work
everywhere.

(In reply to comment #45)
> Is the problem resolved in a software version that can be installed on the
> device where the problem was reported? If yes, then it's resolved. If no, then
> it's not resolved. There's nothing procedural about it, this is a discussion
> about if the status has been correctly set for a particular bug report, and
> entirely within the scope of a bug report, and is how bug trackers work
> everywhere.

Every bug report everywhere is closed when the bug is fixed in the source code,
not when the software is released. And now let this discussion. I'm getting
sick of it.

(In reply to comment #45)
> (In reply to comment #44)
> > Please stop abusing bugzilla for complaining about procedures. If you think
> > those procedures are a bug, then open a new bug. You're devaluating this bug by
> > going off topic.
> 
> Is the problem resolved in a software version that can be installed on the
> device where the problem was reported? If yes, then it's resolved. If no, then
> it's not resolved. There's nothing procedural about it, this is a discussion
> about if the status has been correctly set for a particular bug report, and
> entirely within the scope of a bug report, and is how bug trackers work
> everywhere.

This is not an N900 bugzilla, it's a Maemo bugzilla.

Regarding Maemo 6 on N900, that's not an issue for bugzilla, but customer care,
or something like that.

Comment 48 Andrew Flegg 2011-02-05 12:12:53 UTC

With the Community SSU we now have a mechanism to easily ship such
modifications to a wide base of users.

So, if someone wanted to revisit the patches linked to by pvanhoof, we might be
able to get some movement on it.

http://mail.gnome.org/archives/tinymail-devel-list/2007-October/msg00040.html

http://wiki.maemo.org/Community_SSU

(In reply to comment #48)
> With the Community SSU we now have a mechanism to easily ship such
> modifications to a wide base of users.

Excellent!
> 
> So, if someone wanted to revisit the patches linked to by pvanhoof, we might be
> able to get some movement on it.
[...]

A couple questions/comments
1) should we clone this bug to track delivery of a test package (and then
transition to a stable package) in Community SSU or take this existing bug
over? (FWIW, I'd rather do the former)
2) could someone please build a deb in -devel, -testing or whichever is
appropriate and post the apt CLI incantation to pull/update that single package
from the repo?
  (I'm an RPM guy, so I will not be much help here, sorry. What I am thinking
is a translation or the yum'ism "yum --enablerepo=updates-testing update
tinymail"
3) I'd be very happy to test a package and report back how it works.