--On Wednesday, March 12, 2003 12:58:55 AM -0600 "Eric A. Hall" <[EMAIL PROTECTED]> wrote:
| I'm not trying to start a religious war here, but how much work would it | really be to have a protocol extension which allowed the client to request | flags which have changed since <time>. It seems that all of the difficulty | would be in the implementation (the server data-store), not in the | protocol, and there would be significant benefits to having this option | available in the protocol. Faster resynchronization between sessions would | be very good for all clients, online and offline alike. | | In those cases where it was impractical to store this kind of information, | the server wouldn't implement it, which is reasonable behavior for any | optional extension. | | Ignoring the data-store issues which will dictate whether a specific | server is able to implement the feature, how feasible would this be?
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.
Servers would be allowed to respond with an untagged 'NO token too old' response if they don't have data going back far enough to satisfy the request, in which case clients would have to fall back to what they do now.
The only issue with this is coming up with a reliable way for clients to get the token. That probably means requiring clients to CLOSE or UNSELECT mailboxes in order to get the token at a point after all unsolicited responses have been sent.
Of course implementing this on the server is going to be a pain for some type of mailbox formats and its going to involve managing a lot of meta-data for the mailbox. I've always envisioned this as being done using transaction ids (i.e. each command that changes the state of the mailbox/messages is recorded as a transaction) rather than timestamps. But that's something server vendors can decide on.
-- Cyrus Daboo
