On Mon, 23 Jun 2003, Timo Sirainen wrote: > But if client wants to know it anyway, it's better to let server > check it when it wants to rather than ask it specifically once every 10 > minutes.
The other way is for clients to take "no" for an answer when that "no" means "it is too expensive." The production of quality software requires that one balance user interface desires against what is feasible. It is a common baby programmer mistake to assume that, because a problem is not in ones own piece of the puzzle, the problem therefore does not exist. The sad state of many IMAP clients demonstrates this all too well. These clients fight the IMAP server (and the IMAP protocol) rather than work with it. The result is a heavy burden on the server, and a slow mail reader for the user. > I don't think this would be problematic to implement even with unix > mboxes. You just remember mtime of last check, if it changes you'll do > the expensive STATUS and send it to client (but no often than once in 10 > minutes or so). If you believe that "just remember mtime of last check" is a good idea, then you should love the \Marked and \Unmarked flags. Yes, you're talking about comparing delta mtime instead of mtime vs. atime. Nevertheless, you need to consider how mtime works. The semantics of mtime are different depending upon the UNIX variant (Linux is not like SVR4 is not like BSD) and the software mix installed. The c-client library used by Pine and UW imapd also imposes its own regulations on mtime (albeit in an attempt to make mtime semantics somewhat more regular and predictable). > Even if mail store can't support any shortcuts, it's still no worse than > letting the client do the polling. The difference is that in one case you have a slow server. In the other, you have a clearly stupid client doing a clearly stupid thing. When the user complaints, and site management investigates, it makes all the difference in terms of what gets blamed. > > Does it really matter to a client if there are 44 new messages or 51 new > > messages? Does it really matter to an end user? > No, but it matters that user knows that there actually are new mails. Exactly! So you don't really need STATUS. What's more interesting is to get an event when new mail is delivered to a particular mailbox. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
