Quoting Timo Sirainen <t...@iki.fi>:
On 23.6.2012, at 13.21, Ed W wrote:
But I don't know, whether this is the sort of caching you are
referring to.
what's a point of caching imap, except your webmail service is not
locally connected (localhost or LAN) to imap server?
Asking for items 600-615 from a threaded list, sorted by something,
can be an expensive operation, especially if you just asked for
items 585-600 a moment ago?
Can be, but is it? :) Dovecot attempts to cache/index stuff as well.
Normally there shouldn't be a need for extra caching layer except in
cases of higher network latency.
Timo: I'm not sure if you are saying that all client-side caching is
wrong. If so, I'm going to disagree with you, especially when dealing
with more complex data structures.
Let me first say that I don't take IMAP response parsing to be a
computationally easy action. So it's not just network latency you are
worrying about; parsing a line can be the limiting factor in many
cases. For example, a deeply threaded 400 message mailbox will return
a THREAD response line that will take quite a bit of recursive parsing
to decode.
And various FETCH criteria most definitely benefit from local caching
above/beyond what dovecot provides. An example: BODYSTRUCTURE. This
may be cached on the dovecot side, but when received by the MUA you
have to parse the IMAP BODYSTRUCTURE response (not trivial). You also
have to potentially handle IMAP response codes in the server command
completion line. And the bodystructure data is probably not all that
useful until converted to a usable object on the MUA side, which may
be another relatively expensive operation. So a locally cached
bodystructure object is a substantial performance benefit over having
to recreate this data from the cached data on the dovecot side.
ENVELOPE is similar. Most likely this will be converted to an object
representation in the MUA so you have the same benefits as
BODYSTRUCTURE. Additionally, in IMP we do things like scan for broken
charset headers (e.g. Subject headers that contain non-ASCII
characters) and have some algorithms to fix these issues. This
"value-added" code would be prohibitively expensive if we have to do
it on every mailbox access.
Message flags are another benefit to caching. The list of flags may
be cached on dovecot, but not having to issue a flag FETCH every time
you access a mailbox can be a substantial benefit.
But I will heartily agree that nobody should be caching things like
headertext or bodypart data. There is little/no benefit you receive
from caching this locally. This is where you should be leveraging the
storage on the IMAP server.
As an MUA author you can't rely on the fact that you are connecting to
a competent IMAP server. You just as likely are going to be
connecting to a server that implements base RFC 3501, and most likely
implements that incorrectly. Not all of us are lucky to connect to
Dovecot (or Cyrus).
So smart caching most definitely can and will increase performance of
an MUA, regardless of caching performed by the IMAP server.
michael
