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