On Tue, 2003-03-11 at 12:21, Timo Sirainen wrote: > 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.
Well, even though the server is already permitted to send unsolicited STATUS 'replies', the client would need to know that the server _will_ do so, hence that the client doesn't need to keep polling. There'd have to be _some_ way for the server to indicate that situation, and probably also you'd want a way for the client to select _which_ folders should be monitored by the server. So the 'STATUS-WATCH' idea seems more useful than silently configuring the server to do it. I wonder if just limiting it to subscribed folders is OK though, or whether we really want the client to be able to give a list? > Right, \Marked is more about if mailbox possibly has \Recent messages > (or something else "interesting"). OK. Hence the only way a client can currently poll for mail in all folders is to execute a separate 'STATUS' command on _each_ one, periodically. > > 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. Sorry, my question wasn't clear. I speak not of the currently-selected folder but of _other_ folders, for which the server will not be sending updates (and besides; flags changes are only a 'SHOULD' anyway). > 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. True; the point of my questions is to establish best practice before I try to assist with that rewrite. I started by adding the capacity to get at an IMAP server by running 'ssh $mailhost exec imapd', and now I'm looking at the rest of the things which annoy me about it. The major one at the moment is the fact that STATUS queries for all folders get queued in one lump, and I have to wait for them all to complete before it'll actually do the next thing that _I_ asked it to ;) Yes, I can make it prioritise commands from a queue and send 'user-driven' requests before background status polling, but in the long term I'd rather eliminate the STATUS requests altogether if possible. > > 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. I'm not sure I agree with that. Consider the case of a folder with 3000 messages in it, which _hasn't_ been modified by another client since it was last used by the client we're sitting in front of. Perhaps we've just selected another folder temporarily and then switched back to the first. Surely it's better to do a single compare of a sequence number (basically a datestamp) than to issue a FETCH for the flags of _every_ message again? I was thinking of a new command where the client can present the 'flags-validity' sequence number which matches its own cached flags for the folder, and be told by the server 'You need to (re)fetch flags for the following messages...'. Which gives the naïve server implementation the option of just saying 'all messages' if anything's changed, or more complicated servers could perhaps keep track of _which_ messages' flags have changed in the last few sequence numbers; keeping 'last changed at' stamps per-message or something so that a client can be given a more limited set of messages for which the flags have changed. -- dwmw2
