On Fri, 2003-02-14 at 20:54, David Woodhouse wrote: > On Fri, 2003-02-14 at 02:30, Not Zed wrote: > > evolution stores a subset of the headers of every message of every > > opened folder in memory. > > Note that when Evolution is separated from the IMAP server by a slow WAN > link, the mere fact that it thinks it's necessary to fetch the headers > for _every_ message even in the mailbox(es) you currently have open is a > bug far more severe than the memory usage.
Hmm, i'm not sure what you mean here. It only fetches the headers that are new. Or if the server is changing the UIDVALIDITY field, in which case we must refetch all headers (as per rfc2060). > You know how many messages there are in the mailbox so you can make your > scrollbar scale correctly. You can fill in the 'unknown' entries in the > list with some suitable placeholder text and replace that text with the > _actual_ message information if and when the relevant list entries are > actually displayed on-screen. You can even fetch the message headers for > the non-displayed messages in the background to populate your cache, as > long as there's no user-driver IMAP activity which should take > precedence -- but there's absolutely no excuse for making the user wait > while you download all the headers, before you even start to display the > list. Actually there's a couple of reasons :) - updating etable has been extremely slow, and very buggy, we tried some incremental update for local mail, and that either caused etable to crash a lot, or if we rebuilt the tree every now and then, it was just way too slow (it really bogs down your system). - partially its the abstraction layers used, although there is actually no technical reason why the current abstraction can't be used in a different way at a lower level and implement this behaviour. - there's still the problem of how to display mail arriving with sorting on, which can make it next to unusable to use the display while new things get added. The main reason is the first, the code hasn't been fast enough, although etable in 1.4 is looking significantly faster so it may become possible. We might even get enough bugs out of it to incrementally build the tree rather than having to discard and rebuild from scratch every time, which would make it easy. The second issue is more work to fix, although, not impossible. We just need to throw out 'folder updated' events during long processing, at the low level imap engine. Lastly, I hate the IMAP code probably more than you do, i have to help maintain it :) Z PS someone else wrote the imap code originally ... _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
