Re: [Evolution-hackers] Introduction and Questions

[Ross Boylan <ross biostat ucsf edu>]

On Fri, 2007-06-08 at 17:11 -0400, Jeffrey Stedfast wrote:
> 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)
The parenthetical remark is pretty interesting.
> 
> 3. if threading behavior is different from other accounts, it will feel
> "weird" to the user.
All good points.  I should explain I'm thinking of a mode that might
kick in only on "large" mailboxes, or as a user option or something like
that.  My main concern is that with very large folders most mail cients,
including evolution, become sluggish to the point of being unusable.
For many of the clients life is much uglier during the initial contact
with the folders than later.  For example, when I move a message into a
folder I haven't opened or operated on in evolution, I'm noticing long
delays (like > 1 minute) while it does something (fetch headers and
create an index?  whatever it is uses some, but not all the CPU).

In this context an responsive but imperfect solution is better than an
unresponsive perfect one.

For example, if evo relies on the server's threads then it will
obviously inherit their behavior, warts and all.  In general I agree
with the point, made recently on this list, that it's desirable for
clients to shield users from server problems (and most users don't know
and don't care that the the "real" problem is with the server).  But if
doing so takes forever, some may be willing to give up on that.

Whether relaying on server side threading, which currently only operates
on the whole mailbox, can solve the performance problems is another
issue.
> 
> >   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.
My impression, based partly on what a (the?) Mulberry developer said, is
that Mulberry gets the entire threaded list from the server.  The time
seems to go into the post-processing, and apparently this gets redone
every time you scroll.  (The developer thought it was time parsing the
response string from the server, though I would think building up a
virtual message list window is a more likely culprit).

BTW, in case people aren't aware, Mulberry was recently open-sourced.
> 
> > 
> > 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.
Worst case the display of the results could be deferred until something
else, like a user hitting a scrollbar, causes a display update.  But I
don't see how this case differs from other things that might change the
display, such as the arrival of new mail.

Ross