[PATCH v4] Re: make maxage use UIDs to avoid timezone issues

[Nicolas Sebrecht]

On Mon, Apr 06, 2015 at 09:00:51PM +0200, Abdó Roig-Maranges wrote:

> hmm... currently the times thing is a bit of a mess.

Not a bit. It IS a mess! While much less messy since Janna entered the
scene. :-)

>                                                      I'm partially to blame for
> this because I introduced the mtimes for quick sync without having a full
> picture... anyway, currently we have the following timestamps attached to
> messages:
> 
> * mtime.
>   - It means: last time this local message changed on disk.
>
>   - We cache it in GmailMaildir.
>   
>   - Stored and cached in the statusfolder as 'mtime'. However, it only makes
>     sense when syncing a GmailMaildir.
>   
>   - It is internal to GmailMaildir. However we have getmessagemtime and use it
>     from the outside of the class because we need access to the status
>     folder... This is "a leak of implementation details" as it is now, but was
>     the easiest way to do it. 

Should be documented why.

> * IMAP internal date.
>   - It means: "time at which the server received the message" (can you
>     confirm?).  

Yes, most of the time. IMAP INTERNALDATE is not strictly defined. The
meaning can change over messages.

>   - It is not cached in IMAPFolder.
> 
>   - It is cached in the statusfolder as time, but not stored! It is passed as
>     rtime when the IMAP folder is on the remote side.
>
>   - It is going to be used for the maxage thing.
> 
> * rtime.
>   - It means: internal date on the remote IMAP.

Yes. That's why I don't understand why you make distinction between
"IMAP internal date" and "rtime". They should be the same thing.

>   - It is passed to savemessage, and is to be used to create local Maildir
>     filenames.
>   
>   - The rtime is cached in the statusfolder too, as 'time', but not stored! I
>     think it is useless.

Yes.

> * date header.
>   - It means: date at which the message was written.
>   
>   - It is used by utime_from_header to affect local modification times. It is
>     decoupled now from rtime, and kept within MaildirFolder.

Yes.

> > I'm not sure about merging rtime and mtime. They have different purposes
> > for sure. mtime might be compatible with how rtime is computed or not, I
> > don't know.
> 
> Well, the mtime and IMAP internal time are properties of a message that have
> quite similar meaning. Since one applies to IMAP and the other to Maildir, I
> think merging them is ok, and simplifies things a little bit, making IMAPFolder
> and MaildirFolder more homogeneous. 
> 
> The rtime, of course is different.

Well, remote IMAP INTERNALDATE /is/ rtime. We _mirror_ the remote IMAP
INTERNALDATE (within the filename).

>                                    In the context it is used, means whatever
> timestamp is attached to the message on the remote.

Yes. Much better definition than the above "IMAP internal date" at the
beginning. ,-)

> What I propose is something like this:
> 
> 1. All folders will implement getmessagetime. Maildirs returns unix mtime, and
>   IMAP return internal time.
>
> 2. That time, is cached in messagelist as 'time', on all IMAP and Maildir folders.
> 
> 3. We store, and cache ONLY the local time in statusfolder.

...for Gmail only.

> 4. We get rid of getmessagemtime, and use getmessagetime instead.
> 
> The main point of this making objects more uniform so we can reuse more
> code. After those changes, we could probably move some shared code to
> BaseFolder.

I can't tell for now. Wait for the coming cycle about deep refactoring.
I intend this cycle for big changes like this. ,-)

-- 
Nicolas Sebrecht