Re: CONDSTORE: STORE UNCHANGEDSINCE 0

[Bron Gondwana <[e-mail]>]

On Thu, Mar 13, 2008 at 06:31:34PM +0200, Timo Sirainen wrote:
> On Mar 13, 2008, at 5:57 PM, Alexey Melnikov wrote:
>
>> Timo Sirainen wrote:
>>
>>> What happened to this?
>>>
>> I need to publish CONDSTOREbis draft at some point which contains the fix. 
>> I don't have time or energy to do this now. I should find some time once 
>> all my Lemonade drafts are approved for publication.
>
> Are there going to be other changes? The main problem I currently have 
> implementing CONDSTORE is that I'd rather not want to figure out 
> HIGHESTMODSEQ value when selecting a mailbox unless I know the client wants 
> to use CONDSTORE. I started to wonder if it would work nicely if a SELECT 
> mailbox returned [NOMODSEQ] but the first CONDSTORE enabling command would 
> cause * OK [HIGHESTMODSEQ n] to be sent.

How do you calculate the MODSEQ if you're not using some sort of fast,
atomically incrementable counter?

I guess it would be viable to store a "changed timestamp" or something,
and then lazily calculate a modseq only when something using CONDSTORE
viewed the mailbox - but that sounds pretty messy and potentially
expensive.  I've only read the Cyrus implementation, but it makes sense
in that it has a per-mailbox highestmodseq which gets updated while
the mailbox index is locked (hence the atomic bit) and the index records
themselves all have a modseq value which gets created/updated on any
store/append action.

My initial reaction to CONDSTORE when I saw it go in Cyrus was lukewarm,
but having recently actually tried to figure out the distribution of
bandwidth use on our servers (FastMail.FM) we have discovered that IMAP
TAG UID FETCH 1:* (FLAGS) calls are a huge part of our traffic.  It's a
big pain that in vanilla IMAP there's no way for a client to say "tell
me what has changed" on a 200k message mailbox.  I'd like to see
CONDSTORE used more generally now!

Regards,

Bron.