Re: [Evolution-hackers] Introduction and Questions

[Jeffrey Stedfast <fejj novell com>]

On Fri, 2007-06-08 at 12:23 -0700, Ross Boylan wrote:
> On Thu, 2007-06-07 at 09:25 -0400, Jeffrey Stedfast wrote:
> > it's not possible to do better w/o dropping features like message
> > threading.
> > 
> > In fact, the above minimalizing of header fetching already breaks the
> > quick context-menu "vfolder on mailing-list" and "filter on
> > mailing-list" features as well as making vfoldering on mailing-list
> > oodles slower (if it even still works after disabling the headers) 
> What about letting the server do the threading, if it can?

1. not all servers support it, so we need to implement threading
client-side anyway

2. not all servers do it /correctly/, so we'd need to have a lookup
table of server idents so we knew when to fallback (note that every mail
client I know of that tried to be smart and let the server do the
threading has lived to regret making this decision)

3. if threading behavior is different from other accounts, it will feel
"weird" to the user.

>   I realize
> not all can, and probably all will seem not as smart as they could be
> (or just different from how threading would be done in evolution).  But
> otherwise, there's no way around getting lots of headers, and that is a
> huge hit with big folders.
> 
> That's the theory; the practice seems uglier.  I tried mulberry, which
> is supposed to make very good use of IMAP.  In many ways it does, but
> its use of server-side threading doesn't work too well.  It seemed to
> get the response back quickly from the server, but then take minutes
> processing and parsing this response.  Furthermore, every time one
> scrolls the window, it does it all over again.
> 
> The other problem with server-side threading is that it threads
> everything.  In principle it might make more sense to retrieve a window
> of headers and thread them.

actually, I think this is what Mulberry is doing - or at least that
would make sense if it has to re-fetch thread info when you scroll.

> 
> The window might not include all items in the thread, but that seems a
> reasonable trade-off to me in return for decent performance.  One could
> do a more thorough job in the background and update when it finished.

but then you have items in the list moving around as more thread info
becomes available which would be annoying to users, imho.

Jeff