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. > 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. > 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, 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'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). Basically, you need to look at what comsat/biff do, and realize that although those programs are obsolete, they are on the right track. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
