> 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. 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. _______________________________________________ evolution maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution
