On Tue, 2003-03-11 at 17:15, Mark Crispin wrote: > On Tue, 11 Mar 2003, David Woodhouse wrote: > > By 'ctime' I meant the inode ctime on the underlying file system, for > > the inode of the mbox file. > > I know what ctime is.
Sorry :) I was just confused because you seemed to be saying there was a way for the client to query the ctime (or at least issue a command less slow than STATUS) and decide for itself whether to re-issue a STATUS command or not; which doesn't seem to be the case. Maybe I misunderstood what you had said. > > When configured to 'check for mail in all folders' Evolution is issuing > > a LIST command, and then for each mailbox listed it's issuing a STATUS > > command. I wasn't aware of any way in which we could know at the client > > side that a given mailbox doesn't need checking. As discussed, even the > > \Unmarked flag doesn't necessarily mean that there isn't new mail in a > > mailbox which _this_ client hasn't previously seen. > > That isn't checking for new mail; rather, it is checking for a need to > synchronize a particular client instance. The precise reason for doing this is because it's looking to see whether it needs to update its folder tree widget by turning a folder name bold and putting the number of unseen messages in parentheses by it, to inform me (the user) of the fact that there are new messages therein. We can describe that either as 'checking for new mail' or as 'checking for a need to synchronise', but I suspect it doesn't really make a lot of difference which terminology we use. > > I'm perfectly happy to fix Evolution if a correct fix is possible -- > > it's just that I couldn't see one myself. > > An IMAP server with fast STATUS metadata (such as Cyrus) will help you do > faster polling, That was the reason for switching to Courier. I considered Cyrus briefly but it doesn't do PREAUTH when invoked from the MUA via 'ssh $mailhost exec imapd'. > but if the client really wants to maintain synchronization > with a great many mailboxes (as opposed to a much more limited set of > "incoming" mailboxes) then polling is not the correct fix. > > The correct fix is MTA-based notification, not client-based polling of an > IMAP or POP server. I'm not sure what you mean by 'MTA-based notification'. I would have said that the correct fix as far as the _client_ is concerned is asynchronous notification by an IMAP server of such changes. Hence the suggestion for an IMAP extension to provide just that. And you're arguably right that the correct way to _implement_ that is MTA-based notification rather than having the IMAP server itself do polling of individual mailboxen. > I've been working on a notification facility, largely > in secret because history has shown that the best way to preclude progress > is to have a committee work on it (as in there have been many prior > attempts and all have collapsed under their own weight). Were you considering this as an IMAP extension or a completely separate connection which a client must make to the same host for a remarkably similar purpose? -- dwmw2
