Summary | Smarter determination of "next" message |
Queue | IMP |
Queue Version | Git develop |
Type | Enhancement |
State | Resolved |
Priority | 1. Low |
Owners | slusarz (at) horde (dot) org |
Requester | jan (at) horde (dot) org |
Created | 08/23/2012 (4703 days ago) |
Due | |
Updated | 08/29/2012 (4697 days ago) |
Assigned | |
Resolved | 08/23/2012 (4703 days ago) |
Milestone | |
Patch | No |
commit 9a8e52151796ae099e59de76ec0fc538b0e2d7be
Author: Michael M Slusarz <slusarz@horde.org>
Date: Thu Aug 23 14:54:34 2012 -0600
Request #11373: Improvements to pref-fetching algorithmFetch both the previous and next unseen message.
Fetch in all polled mailboxes, not just INBOX.
imp/docs/CHANGES | 2 +-
imp/js/dimpbase.js | 15 ++++++---------
imp/package.xml | 2 +-
3 files changed, 8 insertions(+), 11 deletions(-)
http://git.horde.org/horde-git/-/commit/9a8e52151796ae099e59de76ec0fc538b0e2d7be
State ⇒ Resolved
commit 9a8e52151796ae099e59de76ec0fc538b0e2d7be
Author: Michael M Slusarz <slusarz@horde.org>
Date: Thu Aug 23 14:54:34 2012 -0600
Request #11373: Improvements to pref-fetching algorithmFetch both the previous and next unseen message.
Fetch in all polled mailboxes, not just INBOX.
imp/docs/CHANGES | 2 +-
imp/js/dimpbase.js | 15 ++++++---------
imp/package.xml | 2 +-
3 files changed, 8 insertions(+), 11 deletions(-)
http://git.horde.org/horde-git/-/commit/9a8e52151796ae099e59de76ec0fc538b0e2d7be
the current message.
I'm also thinking that we could extend the pre-fetching to any mailbox
that is marked as polled. This is a reasonable compromise since the
user has indicated that this is a mailbox where he/she expects to
receive new (unseen) messages.
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Smarter determination of "next" message
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
State ⇒ Accepted
the interface feel much faster. Unfortunately it only works if you
read messages from top to bottom. This is not always the case. A
common scenario is to sort the messages from newest to oldest, but
start reading from the oldest unread message and go up through the list.
It would be smarter if the "next" message is determined at least by
the sort order, if not by the way the user currently moves through the
message list, i.e. if he navigated one message up, prefetch the 2nd
next message up and vice versa.