2 code change requests: FETCH instead of UID FETCH and using IMAP 'ID' at login time
Sebastian Spaeth
Sebastian at SSpaeth.de
Mon Aug 8 16:09:48 BST 2011
On Thu, 21 Jul 2011 16:19:56 -0700, Marc MERLIN <marc at merlins.org> wrote:
> I was told the following:
> "Also, it looks like offlineimap is using UID FETCH, which means that
> after every fetch, we check and update the folder information if any
> changes have been made. This means you pay a performance penalty
> every time you receive a message or mark a message as read or
> whatever. You would get more consistent performance using plain
> FETCH. "
>
> Is it possible to change the code to use just FETCH instead?
This is interesting information. Looking at the IMAP RFCs I don't see
any information about checkpointing and updating when using UID vs
FETCH, so this must be some implementation specific issues, I guess. You
were saying that you are using gmail for that?
The problem is that the FETCH command takes a message sequence number
and these can change for every new SELECT of a folder. The UID command
takes the Message UID (which never changes) as its argument which makes
much more sense for us (as this is how we keep track of messages). So
using the FETCH command would require us to make lots of changes and
auditing to: 1) additionally gather the message sequence number of a
message when selecting it and 2) make sure we never re-select a folder
before we make use of it and 3) we use exactly the same thread to
download a mail as has been used to gather the message sequence
number. Overall, I am a bit sceptical that all this would be implemented quickly.
Also, try to use the sqlite status backend rather than the plain text
one. For many emails and lots of syncs I would suspect it makes quite
some difference.
Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110808/abb0239a/attachment.sig>
More information about the OfflineIMAP-project
mailing list