On Tue, 2003-03-11 at 12:20, David Woodhouse wrote: > 2. The other problem with the IDLE extension is that it only affects the > one currently-selected folder. Is there any work on, or discussion of, > an extension similar in spirit to 'IDLE' but which also permits the > selection of multiple folders for asynchronous status updates. It's > common for an IMAP client to be checking for mail in _all_ folders (or > all subscribed folders), but this is still only possible via polling.
I've been thinking that server could send STATUS-replies whenever it notices new mail in mailboxes. Maybe a "STATUS-WATCH (mailboxlist)" or similiar command for that. Or that configuration could even be done at server side so it might not even require changes to clients, assuming it updates it's internal counts whenever it sees STATUS reply. > 3. On a related note -- is it permissible for a client to rely on the > \Unmarked flag to optimise away a STATUS command for certain folders > when polling for new mail? I suspect not -- it seems to me that it's > permitted for a server to show a folder as \Unmarked if _another_ client > has selected that folder since the new mail arrived, hence that a client > must issue STATUS for _all_ folders in which new mail might have > arrived, regardless of their Marked/Unmarked status. Right, \Marked is more about if mailbox possibly has \Recent messages (or something else "interesting"). > 4. What mechanisms exist or have been discussed to allow client-side > caching of message flags (such as \Seen, \Answered in particular). Server should send flag updates to client. I think it's pretty safe to cache the flags for the current session and assume the server notifies of any changes. > I > observe that Evolution downloads flags for _all_ messages in a folder > the first time a folder is selected after startup. If flags are changed > by another client, Evolution won't notice until it's restarted. Evolution's IMAP support is pretty bad. I've been rewriting it for a while with one of the Ximian guys, but it's not that far yet and I've other things to do too. > Would it be feasible to add something like a flags-sequence-number which > is incremented each time flags for existing messages are changed, which > a client can use to invalidate its cache of message flags? Probably not, it wouldn't be that much different from simply fetching the flags instead of flag-seq-number.
