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

[Not Zed <notzed ximian com>]

> 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.