> we were talking about server caching of the ENVELOPE data such that > responses were fast. If the server has to convert messages from their > internal data format into MIME and then parse them to extract the > headers to build the ENVELOPE response each time ,then it might actually > be faster to get the full header block.
But, because we dont request that every time, it isn't really much difference anyway, in the end. Its only a practical problem because you can't do anything else while its happening, which is hard to fix because etable is so slow and impractical to change in the imap backend because it can't do things incrementally very efficiently. There are other things to look at anyway. If we just fix the get_folder_info stuff to run off the foldersummary nomally, and change it so that we use folder.refresh_info to update unread counts rather than calling get_folder_info(!FAST), it would make quite a significant change to the 'feel' of the existing code. And definitely never use STATUS, which is extremely expensive on some servers. The get_folder_info thing locks up the whole server until the entire process is finished, which can take a (very) long time, at least if we run it from the client it will be more granular, and we could even do some tricks to pause what we're doing if we get busy doing other things. _______________________________________________ evolution maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution
