Subject: [imapext] "NOMODSEQ until needed" optimization

From: Dave Cridland <[email-masked]>
Date: Thu, 23 May 2013 22:40:10 +0100

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" <[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 -- http://trojita.flaska.net/
> ______________________________**_________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/imapext<https://www.ietf.org/mailman/listinfo/imapext>
>