On Wed, 12 Mar 2003 11:28:04 -0500 Cyrus Daboo <[EMAIL PROTECTED]> wrote:
> The idea of adding a proper 'dynamic' synchronization capability to IMAP
> has been discussed before. You actually need to go further than has been
> discussed in this thread in that its also good to get the list of messages
> expunged since the last time.
>
> The solution to this involves adding a parameter to the SELECT command that
> is an opaque 'token' (which may be a timestamp or a transaction id or
> something else) and returns the UID of messages that have been expunged (as
> one untagged response) and messages whose state (flags, annotations etc)
> has changed (as another untagged response). The set of new messages can be
> inferred from the server in the usual manner so that data set does not need
> to be returned. Note that actual flag data is NOT sent - just the UID. That
> way clients get to decide exactly when they fetch the data.
As it turns out I had implemented a private TAG extension that did this,
except that it had independent TAG commands -- it wasn't tied to select
and close. I wanted to see how big a win it was for resynchronization.
The answer -- the bigger the mailbox and the lower the transaction rate
into the mailbox, the bigger the win. If the mailbox was small or had a
high transaction rate (lots of expunged and new messages) then it wasn't
that much of a win.
A number of mailboxes do have this type of activity pattern -- my inbox
being one of those.
The basic set of commands (if I remember correctly) was something like:
TAG - get a transaction tag from the server. This creates a marker in
the server from which it relative changes can be calculated.
FETCH CHANGES {TAG} - which returns the UID's of messages that have been
expunged or state has changed since the {TAG}.
I never wrote it up, I just wanted to see what it would do -- which I have
described above. It substantially reduced the resynchronization
roundtrips for large mailboxes with (relative to the number of messages in
the mailbox) low numbers of transactions between resynchronization.
Clearly I didn't think it was that important because I never wrote it up.
It did work well though. We already maintained transaction state in our
server to do shared mailbox notifications so it wasn't hard to do on the
server side.
Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[EMAIL PROTECTED]>
Phone: 780-424-4922
