feature: IMAP-GMail

Abdó Roig-Maranges abdo.roig at gmail.com
Mon Apr 6 17:05:14 BST 2015


>         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

The patch is quite harmless. The bulk of it are a couple of big reindents.


More information about the OfflineIMAP-project mailing list