feature: IMAP-GMail
Abdó Roig-Maranges
abdo.roig at gmail.com
Mon Apr 6 17:05:14 BST 2015
Hi,
> local remote mtimes
> ---------------------------------------------------------------
> 1. GmailMaildir Gmail yes
> 2. GmailMaildir IMAP invalid configuration
> 3. IMAP Gmail ignored
> 4. Gmail Gmail no
> If the local is IMAP (3), mtimes don't make sense. it should not be
> computed.
We could use internal IMAP dates for this? It would unify mtimes across all
folders, and go a small step in making cache entries into a global type.
> If the local is Gmail (4), mtimes still don't make sense but labels
> changes should be propagated. Though, I have no idea how label changes
> are handled on Gmail (do they get a new UID?). I'm afraid there's no
> simple way to cleanly support it.
Label changes on gmail are detected, easily because we fetch all labels on all
messages every time!
The purpose of calling getmessagemtime is to store it in the statusfolder. This
is a bit ugly, the mtime is ONLY used by GmailMaildir (dstfolder). However, we
can't make it into a private thing of GmailMaildir, since the dstfolder has no
access to the statusfolder!
To Make Gmail-Gmail work, we could either:
1. make getmessagemtime return 0 (or something meaningful, like the internal
IMAP date) on GmailFolder.
2. Somehow let the dstfolder have access to the statusfolder, and make the
mtimes truly a destination-local thing.
It follows, in a new message, a patch that properly checks that dstfolder
supports labels. This addresses the commented lines in Janna's patch.
The patch makes the check explicit, and returns immediately if dstfolder does
not support labels. Before we were testing this with a big try block. That was
ugly.
The patch is quite harmless. The bulk of it are a couple of big reindents.
Abdó.
More information about the OfflineIMAP-project
mailing list