On Tue, Mar 11, 2003 at 01:59:26PM +0000, David Woodhouse wrote: > 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.
Well, yes. The reason I want it is that I'd want to see new mail immediately when it comes, instead of only when client decides to poll for it. It doesn't really matter to me if client still does the polling. > 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? Subscribed list could be pretty large. > 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. It's also possible to create a connection for each checked mailbox and issue IDLE in each of them. I don't know if it's such a good idea though. > True; the point of my questions is to establish best practice before I > try to assist with that rewrite. So far I haven't tried to do any special optimizations. I just want it to work. > 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. That's actually what I did first too :) Did you get it to work well? I just couldn't figure out any good way to make it ask password, so I never actually began using 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. How about just getting a faster server :) My STATUS replies near instantly. > 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? Using multiple connections would also help with this. Then you wouldn't be temporarily switching between mailboxes. > 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. Hmm. Perhaps. SELECT INBOX (FLAGS-VALIDITY 100) .. * OK [FLAGS-VALIDITY 105] 1:4,5:10 ... * 5 FETCH (FLAGS (..)) * OK [FLAGS-VALIDITY 106] But I'm still not sure if it's worth it. Client doesn't _have_ to update flags for all messages. You probably only care about the unseen count which you can get with STATUS, and the flags for visible messages. Fetching flags for only the 20 messages or so isn't slow at all. That would require some changes to client, but probably not that much.
