mailing list archives

The RFC states that the mod-sequence represents the highest modification to
a given mailbox.  If a mailstore only stored a global (account-wide, across
all mailboxes) mod-sequence, could one simply return the current value of
such a global mod-sequence when the HIGHESTMODSEQ is called for
(SELECT/EXAMINE/STATUS)?

Obviously using this value would trigger the client to followup with a
request to find out what has changed since it last sync'd, even if nothing
has changed.  Should a client be expected to behave reasonably if it's
FETCH CHANGEDSINCE or SEARCH MODSEQ returned items where the highest
mod-sequence was less than the advertised HIGHESTMODSEQ or worse, there
were no results at all when some were expected?

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20120327/73270912/attachment.html>

On Tue Mar 27 22:49:55 2012, John Galton wrote:
> The RFC states that the mod-sequence represents the highest  
> modification to
> a given mailbox.  If a mailstore only stored a global  
> (account-wide, across
> all mailboxes) mod-sequence, could one simply return the current  
> value of
> such a global mod-sequence when the HIGHESTMODSEQ is called for
> (SELECT/EXAMINE/STATUS)?
> 
> Obviously using this value would trigger the client to followup  
> with a
> request to find out what has changed since it last sync'd, even if  
> nothing
> has changed.  Should a client be expected to behave reasonably if  
> it's
> FETCH CHANGEDSINCE or SEARCH MODSEQ returned items where the highest
> mod-sequence was less than the advertised HIGHESTMODSEQ or worse,  
> there
> were no results at all when some were expected?

It'll work, it just might be less efficient.

But if the client is using QRESYNC, it'll be no different at all, I  
suspect.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

On 28.3.2012, at 1.26, Dave Cridland wrote:

> On Tue Mar 27 22:49:55 2012, John Galton wrote:
>> The RFC states that the mod-sequence represents the highest modification to
>> a given mailbox.  If a mailstore only stored a global (account-wide, across
>> all mailboxes) mod-sequence, could one simply return the current value of
>> such a global mod-sequence when the HIGHESTMODSEQ is called for
>> (SELECT/EXAMINE/STATUS)?
>> Obviously using this value would trigger the client to followup with a
>> request to find out what has changed since it last sync'd, even if nothing
>> has changed.  Should a client be expected to behave reasonably if it's
>> FETCH CHANGEDSINCE or SEARCH MODSEQ returned items where the highest
>> mod-sequence was less than the advertised HIGHESTMODSEQ or worse, there
>> were no results at all when some were expected?
> 
> It'll work, it just might be less efficient.
> 
> But if the client is using QRESYNC, it'll be no different at all, I suspect.

Well, some QRESYNC capable clients might think that they're being smart and syncing only mailboxes that have changed, but in this server all of the mailboxes have changed, so the client might SELECT all of them.. Then again I don't know if any clients are really doing (or planning to do) that.

Would work better if you kept a per-mailbox HIGHESTMODSEQ even if they point to one shared modseq counter.

On Wed, Mar 28, 2012 at 01:42:23AM +0300, Timo Sirainen wrote:
> On 28.3.2012, at 1.26, Dave Cridland wrote:
> > It'll work, it just might be less efficient.
> > 
> > But if the client is using QRESYNC, it'll be no different at all, I suspect.
> 
> Well, some QRESYNC capable clients might think that they're being smart and syncing only mailboxes that have changed, but in this server all of the mailboxes have changed, so the client might SELECT all of them.. Then again I don't know if any clients are really doing (or planning to do) that.
> 
> Would work better if you kept a per-mailbox HIGHESTMODSEQ even if they point to one shared modseq counter.

That's what we're doing in conversations-enabled Cyrus at FastMail.  I
haven't yet pushed it to master for 2.5, but it's probably what we'll do.
One counter across the entire user, but then keeping the actual HIGHESTMODSEQ
per folder.

The more interesting bits are how to handle shared mailboxes in this case.
I suspect every one will be its own "modseqroot", rather than the shared
root per user.

The good thing about the global counter is that we have a special call to
read just that, and if it hasn't changed then we know ALL folders are
unchanged.  We also keep a global UIDVALIDITY counter per user, and any
rename, create or delete increments that counter, so we can just use the
single counter to know if a new LIST needs to be sent.

Bron.