On 02.08.2010 13:26, Ed W wrote:
- We need threading when retrieving the inbox list
- But.. imap THREAD results are also retrieved when opening the email
view - it's not clear why it's needed here?
As I've said previously, we need to jump over messages (using navigation buttons) in the same order as they are on the messages list.
- It seems like we need to know something for the Next/Prev buttons to
work, but why not restructure those to be an ajax call like "Fetch('next',UID)" so that the "next" in order email is looked up only at the moment we click, rather than looking it up (possibly needlessly) for every email? This seems to be a big win?
This could be a solution, but this way we cannot e.g. disable Prev button when there's no previous message.
- Further it appears that if you only wish to find the Next / Prev email
from a given message then there is a shortcut possible. The THREAD results are in depth first order so we don't need to parse them to move next/prev, we simply find the current UID in the list and then find the next id either before or after? So where we are using the THREAD simply as an ordering then we can simply locate the ID and move a few characters each way
see below...
- It's also not clear why a SORT is done when the message view is
shown? Presumably this is part of the same thing as above? However, surely we only need one or the other? Can we optimise and avoid retrieving unneeded data here?
- I'm presupposing here that the threads are returned in the correct order?
THREAD commad uses DATE header for sorting, so if you've set sorting to e.g. ARRIVAL we must call SORT to re-order messages. I've said before, set order to DATE or NONE and you'll see that SORT is not called.
I haven't yet re-profiled the code (xdebug seems helpful), but Alec suggested that a lot of CPU is spent in rcube_imap_generic::parseThread() - Just eyeballing that it seems like this could be done without the recursion - this seems like it could be a win?
Maybe.