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

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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]