Re: [Evolution] [Fwd: Re: Tunning for large number of files in INBOX]

[Jeffrey Stedfast <fejj novell com>]

On Wed, 2005-07-06 at 11:37 +0800, Not Zed wrote:
> > A huge slowness for Evo IMAP is the fact that it has to ask for
> > whole-headers in order to support vfoldering on mailing-lists,
> > attachment icons in the message-list, etc.
>
> This is only 'much faster' if the server caches this info - some do not,
> and infact have to create the info from the header anyway.  Fetching
> headers isn't really the problem with evo's imap - this is only done
> once.

true... but it seems many do cache this info. Even GroupWise caches it
now I think :)

> Anyway the previous post about using server-side threading etc isn't
> really practical - evolution's mail abstraction can't expose it, the
> tree view can't use it (i mean at all, the tree view needs info on ALL
> headers before it can do anything useful, like present a useful
> scrollbar), and even if all that was possible, i think you'll find it
> would just slow things down in most cases.
>
> Since: normally you dont have to get a lot of new messages (the one time
> startup cost is amortised over all following uses), vs having to get
> fewer headers more often with more latency.
>
> It would result in massively more complex code which would have to take
> into account that not all servers support server-side sorting/threading.
> The design results in a mixing of backend model and front-end view which
> would be hard to reconcile, if e.g. you had 2 open views of the same
> folder with different sorting options.
>
> Yes i've considered it, no i dont think it is practical or very useful
> in our case.

agreed.

Jeff