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

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

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]