On Fri, 20 Jun 2003, David Woodhouse wrote: > Do we agree that however we define 'new mail', '\Marked' status in most > practical circumstances will mean the same to a client as no status at > all -- it's '\Unmarked' which is the interesting one since it means that > you can skip the folder. Because the behaviour is as follows: > > No status --> folder _may_ have new mail --> check it. > \Marked --> folder probably has new mail --> check it. > \Unmarked --> folder doesn't have new mail --> skip it.
That's one possible implementation/interpretation. Here's another: No status --> folder _may_ have new mail --> check it. \Marked --> folder probably has new mail --> go there. \Unmarked --> folder doesn't have new mail --> skip it. The difference is that in the "no status" case, an extra check is made, whereas in the \Marked case, the server's "probably" is good enough. In your case (wanting to check for not \Seen status), you probably want: No status --> folder _may_ have unseen mail --> check it. \Marked --> folder probably has unseen mail --> go there. \Unmarked --> folder _may_ have unseen mail --> check it. This is why you need to have all three states defined in the protocol. The *server* may abolish one or two of the states, but you have to understand what that means in the context of the definitions. > > The fallacy is the presumption that your definition for "have new mail" is > > a global definition that applies in all cases. > I defined 'new mail' as that mail which is not \Seen. You define it (at > least where we are using it in this context) as mail which is not > \Recent. "My" definition is the IMAP definition: "new mail" are messages which have \Recent and do not have \Seen. The definition of "new mail" in an MUA (or to a user) may be something else entirely. "Not have \Seen" is a perfectly reasonable definition in that context. > The client didn't know that all I was doing was fetching one message. In > all probability, the client is pine. Pine always announces new mail. Hence the human user saw the new mail, and for whatever reason elected not to read it at that time. If the user subsequently wants those messages to cause that mailbox to show up in a check, the user will have to do a STATUS-based check instead of a LIST-based check. > It duplicates the UNSEEN value from STATUS in precisely the same manner > as your suggested interpretation duplicates the RECENT value from > STATUS, surely? \Marked and \Unmarked do, indeed, reflect \Recent. But this is for a very real implementation issue with mail stores that have "last read" vs. "last write". Golly gee, that happens to reflect a lot of the installed base of mail stores. > I thought that the idea behind the \Unmarked flag was that we provide > the client with an optimisation -- a way to know that it doesn't _need_ > to issue STATUS for certain mailboxen. That's exactly what it does. But you have to understand what the optimization is, and *why* it is an optimization. Just about every mail store in the word has (or can easily perform) a "last read" vs. "last write" comparison. Although this comparison is not a precise match for "has \Recent messages", it is close enough to be so for all intents and purposes. UW imapd, or at least modern versions, goes to considerable effort to make this as near to a guarantee as possible. This is also how the UNIX shell for the past 30 years has decided whether or not a user has "new mail". That's also how it was done on at least three other operating systems. Not every mail store has a binary "has messages without \Seen set" metadata bit. Nor can all mail stores evaluate this without actually looking at every message in the mailbox. The whole point is that this is costly. There's no "optimization" if it's costly for the server to perform the task. When you write a client, you must consider the cost of your client's demands on the server. The fact that the task is performed on the server does not mean that the costs cease to exist. > Clients which could use \Unmarked status to optimise away > STATUS calls for mailboxen include all clients which keep some kind of > tree representation of mailboxen, with a number of unseen messages by > each one, perhaps highlighting those where that number is nonzero. > > That's Evolution, Kmail, Outlook for a start, is it not? AIUI they're > all interested in \Seen not \Recent. If so, then \Unmarked is not for them. They have to use STATUS, and the LISTEXT work (which will offer effectively wildcard STATUS) will be of interest to them. If the server refuses to supply wildcard STATUS, then either the client has to do a STATUS for each individual message, or take the hint from the server and base "new" based on \Recent instead of not \Seen. Quite frankly, I would rather that a client take a hint than be slower than cold molasses in January. See above about "taking cost on the server into account". -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
