[PATCH] Re: IMAP: improve quickchanged() performance

Nicolas Sebrecht nicolas.s-dev at laposte.net
Thu Apr 14 18:46:58 BST 2011

On Tue, Apr 12, 2011 at 07:32:11PM +0200, Sebastian Spaeth wrote:
> On Tue, 12 Apr 2011 19:17:06 +0200, Nicolas Sebrecht <nicolas.s-dev at laposte.net> wrote:
> > Not sure. Are we talking about _remote_ changes while syncing?
> Yes, the quickchanged() checks if it should perform a regular sync or
> not and it looks at changes on REMOTE.

So, come back to my original question:

> > Can't we try to fetch a deleted UID, then? How do we handle such case?

IOW if we don't check for changes on remote while syncing, I wonder if
we won't do insane things like trying to fetch a mail which was just
deleted (and possibly crash).

> If a message only got flagged as Trashed, it will still be there and be
> included in the count. Only if the deleted message has been expunged, it
> will be be gone. And then the message count would be reduced by
> one. (Does that answer your question?)

Partially. The good question is: do we handle the case nicely?

BTW, you /seem/ to assume that the change comes from a user entremise.
I think we should have a more widely approach: what appears to _us_ as a
deleted mail could only be a mail which was _moved_ from a folder to
another. We really don't know how IMAP servers handle such cases.

So, we don't know and _don't care about_ what was done on the server. We
only matter about "are we still sane when unexpected things happen on

>                                        A change on REMOTE occured if it
> a) has a different number of messages than we have recorded in the
> statusfolder and
> b) the highest UID on REMOTE is not the highest UID in the status
> folder.
> It is case b) that I am not sure about if it brings a lot of
> benefits. It catches some cases of changes on REMOTE that are not caught
> otherwise, but it also means one more IMAP roundtrip per folder.
> Not sure at all. We can probably leave it as it is now and think about
> it when we picked all other low hanging fruit :-).

Nicolas Sebrecht

More information about the OfflineIMAP-project mailing list