On Wed, 20 Feb 2008, Per Foreby wrote:
I suppose you mean caching info from the headers.
Basically the ENVELOPE and BODYSTRUCTURE.
Sounds like this could speed up things quite a bit, at least for smart imap-aware clients. But most people probably use firefox, outlook or som other pop-like client that downsloads everything and keeps a local cache.
Yes. Hence the issue. The author of Dovecot made a good analysis of the tradeoff here.
One way to reduce the tradeoff would be not to bother caching this stuff unless the client fetches ENVELOPE and/or BODYSTRUCTURE. So a user with a dumb POP-like client such as Outlook would never have a cache.
I guess the implementation would mean another .mixsomething meta file. In that case, it would be nice to have a mix tools to rebuild this file.
In the case of the .mixsortcache file, the rebuild procedure is simply to delete it. I probably would do the same thing with the new cache. Is there a reason why this isn't good enough?
By the way, have you considered automatic rebuild of meta files? Since imapd detects corrupt files, it wuold be easy to rebuid or remove the automatically.
I don't really want to do completely automatic rebuild from imapd, since some of the rebuild procedures are damaging and I hope that an intelligent human would make (and take responsibility for) these decisions.
imapd already does a lot of error recovery and correction in cases where it perceives that it can remediate the problem without data loss. I will continue to add more of these over time.
On the other hand, I can't remember when I last needed to rebuid something, so this is probably not an important issue.
That's how I hope that most people will feel! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
