On Tue, 2003-03-11 at 15:09, Timo Sirainen wrote: > 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.
Well, I'd probably settle for that too, and I could do it just by hacking an imapd to offer unsolicited STATUS reports, and of course making Evolution deal with them -- but _ideally_ we'd eliminate the polling from the client in the case where it's not necessary. Until I actually get bogged down in the details of making Evolution behave in a vaguely sane way, I'll stick to chasing the ideal ;) > > 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. True; and it's also true that the set of messages which actually receive new mail is likely to be a subset of that. > > 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. It'd work for me, I suppose, because I'm the only real user of the box I'm using as a server. I wouldn't really want to advocate that as a 'best practice' way of monitoring multiple mailboxes on servers with _more_ than one user though :) > 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. Ask for password? What do you think ssh-agent is for? :) You just want it to use ssh-askpass if necessary. There's a trick to that -- if SSH finds it has a controlling tty, it'll open that and attempt to use it to interact with the user, instead of running $SSH_ASKPASS. So my Evo patches explicitly disconnect from the controlling tty before running the ssh command. It does bring up a window asking for a password. ftp://ftp.uk.linux.org/pub/people/dwmw2/evo/ > How about just getting a faster server :) My STATUS replies near instantly. I've already switched from wu-imapd to Courier, because I objected to wu-imapd trawling through megabytes of each of my project archive folders, checking the status of each message to see if it's unseen, when it had done precisely the same thing one minute ago and the ctime of the mbox file blatantly hadn't changed :) But I'm still the wrong end of a 64K ISDN line and even now, with negligible time actually taken by the _server_ the round-trip time for 40-odd STATUS commands is enough to annoy me. > > 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. It's sort of a viable workaround, but there are limits on the number of connections you can open. Maybe you could keep a connection open for each of the last N visited mailboxes, where N is configurable -- but that still means you have to refetch all flags every time you start up, and when you change through lots of folders (which is a common case when you have lots of separate folders for lists). > Hmm. Perhaps. > > SELECT INBOX (FLAGS-VALIDITY 100) > .. > * OK [FLAGS-VALIDITY 105] 1:4,5:10 > ... > * 5 FETCH (FLAGS (..)) > * OK [FLAGS-VALIDITY 106] That's much like what I was thinking, yeah. > 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. It's true that the client shouldn't be fetching _all_ the message flags. To be honest I'm more annoyed with Evolution for insisting on making me wait while it fetches all the message _headers_ before deigning to show me the ten new messages at the bottom of the mailbox which was all I actually wanted to see. But that's a separate quality-of-implementation issue which doesn't really live on this list. The issue which I thought _did_ merit discussion on this list is that although there's a way to allow the client to cache the message headers and know when to discard that cache, there's no valid way for the client to cache message flags. Even if you're going to be sensible about it and fetch only those flags which you actually _need_ to display, you don't necessarily want to want to have to refetch that information each time you leave and re-SELECT a folder. -- dwmw2
