Subject: Re: [imapext] "NOMODSEQ until needed" optimization

From: Bron Gondwana <[email-masked]>
Date: Sun, 07 Jul 2013 21:54:37 +1000

On Fri, May 24, 2013, at 07:40 AM, Dave Cridland wrote:

  This is a great conversation to be having, but please remember to
  change the subject line...

On 23 May 2013 22:17, "Jan Kundrát" <[1][email-masked]> wrote:

On Thursday, 23 May 2013 21:30:08 CEST, Timo Sirainen wrote:

1. Dovecot doesn't enable modseq tracking until client has requested it
in some way by enabling CONDSTORE or QRESYNC. Until then it says at
SELECT:

* OK [NOMODSEQ] No permanent modsequences

This is probably worth explaining in the updated version. I see the
benefits of not tracking MODSEQs when not ever requested, but I also
understand that clients might want to set a local "don't bother with
MODSEQs" bit in their cache if the server returns a NOMODSEQ. I can
also see that a client might want to open a mailbox and bypass the
usual sycnhronization steps (perhaps it just wants to quickly fetch an
item, etc), so the use case for a MODSEQ-supporting client not enabling
MODSEQs within some sessions seems valid to me. It's a corner case with
potential to cause unpleasant surprises.

Originally, I wanted to suggest not returning either of HIGHESTMODSEQ
or NOMODSEQ at SELECT time, but this is explicitly forbidden by the
RFC.

Do you have any numbers on how much performance is gained by not
tracking the MODSEQs -- i.e. is your optimization actually worth the
complexity?

Cheers,

Jan

--

Trojitá, a fast Qt IMAP e-mail client -- [2]http://trojita.flaska.net/

_______________________________________________

imapext mailing list

[3][email-masked]

[4]https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________

imapext mailing list

[5][email-masked]

[6]https://www.ietf.org/mailman/listinfo/imapext

I'll reply to this one then :)

Cyrus used to not turn on CONDSTORE support for a folder by default -
you had to actually set an annotation on the mailbox first.

I found that we're always rewriting both the record and the index
header every time anyway, so bumping a modseq made sense.  Plus we now
use it to track changed records for flag changes, and for replication,
and ... it just makes sense.  It's too useful to be worth trying to
optimise out.

Bron.

--
Bron Gondwana
[email-masked]

References

1. mailto:[email-masked]
2. http://trojita.flaska.net/
3. mailto:[email-masked]
4. https://www.ietf.org/mailman/listinfo/imapext
5. mailto:[email-masked]
6. https://www.ietf.org/mailman/listinfo/imapext