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.

-- 
Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252
LAN Management System Developer http://lms.org.pl
Roundcube Webmail Developer http://roundcube.net
_______________________________________________
List info: http://lists.roundcube.net/dev/

Reply via email to