PARTIALLY REMOVING MAXAGE (was: [PATCH v4] make maxage use UIDs to avoid timezone issues)

[Janna Martl]

On Fri, Mar 27, 2015 at 06:13:50PM +0100, Nicolas Sebrecht wrote:
>We come to glitches when we upload mails in very short delays.  The
>"order" UIDs are assigned won't match the strict order of the uploads.

Oh, I see.

>The thing is that for maxage, what is relevant is really this upload
>order. Not the UIDs order only. This feature will work ONLY IF we are
>guaranteed that BOTH sides keep the same order of the _messages_.

Yep, I agree that's the issue.

>> I have a feeling that people are more interested in using the IMAP-IMAP
>> thing to copy the contents of one account to a new account. I wonder if
>> we could only support using maxage in this case, i.e. when one of the
>> accounts is empty. That would take away most of the edge cases, and if
>> the messages show up in the other account slightly out of order, it's no
>> big deal; it could have happened naturally, and that's exactly what the
>> min(uid) thing is good at dealing with in the IMAP-Maildir case.
>
>Makes sense. But in this case, we are sightly diverging from the
>definition of maxage. Here, we are taking a UID reference from one side
>once which won't anymore be changed.
>
>This is a good idea and this might really fill the gap of a maxage
>removal. I'm all for this if we don't hijack the maxage definition.
>IOW, this would require yet another configuration option.
>
>Under the hood, relying on the maxage implementation for computation
>would be right. Notice we would need to store the initial min(UID) in
>the cache.

I'm confused; if one folder is empty, then all we'd do is ask for
SINCE(maxage) from the nonempty one, copy those messages to the empty
one, and then refuse to sync those two accounts anymore. How would this
require storing more information?

-- J.M.