Several people have pointed out in the past that the \Recent flag doesn't work when you have more than one client accessing a mailbox simultaneously, you've just pointed out another problem where this occurs. The bottom line is that you can't rely on \Recent to highlight messages, you need to rely on \Seen, since it is a persistent flag (\Recent isn't, it's more of a virtual flag).
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Timo Sirainen > Sent: Saturday, August 02, 2003 5:19 PM > To: [EMAIL PROTECTED] > Subject: Recent flags > > A month ago here was this discussion about new mail notification in > mailboxes. I started thinking about it some more how I'd want the > client's user interface to behave. > > Recent counters are actually quite good. They do exactly what I want, > but only as long as there's only one client having mailboxes SELECTed at > a time, which is usually not the case with me. > > The multiclient behaviour for \Recent simply sucks. Is there any real > reason why it was specified as it was, except just to standardize some > kind of server behaviour? > > I think the wanted \Recent flag behaviour is: "Message arrived the > mailbox after last user interaction in the same mailbox." Problem is how > the server would know which is user interaction and which is client > doing things itself. > > I believe these rules should work quite well: > - When mailbox is SELECTed, all the current messages will be non-recent > for subsequent sessions > - When a message is marked \Seen (most likely a user interaction), all > the current messages will be non-recent for subsequent sessions > (possibly \Deleted flag as well? I'm not sure) > - In all other cases the messages will be marked \Recent for all the > sessions that have the mailbox selected, but also for next session(s) > > That gives the following behaviour: > > Client A has INBOX SELECTed, client B has FOOBOX SELECTed > - A new mail arrives to INBOX > - Client A notices it via NOOP, sees it as \Recent and notifies user > about it by highlighting the mailbox name > - Client B notices it via STATUS (RECENT), or with some new mail > notification extension. Client B highlights the mailbox name as well > > a) User opens some of the new mails with client A, which changes it's > \Seen flag. > - Client A removes the highlight > - Sometimes later Client B issues STATUS (RECENT) which now returns 0. > The highlight is removed. > > b) User notices the new mails with client B, and selects the INBOX. > - New mails are still seen as \Recent > - Client B removes the highlight > - Oops, problem: Client A doesn't know that the highlight should be > removed. > > b's problem can be solved in a few ways: > - Don't just mark the mail to be non-recent for subsequent sessions, > also do it for all the current sessions by removing the \Recent flag and > sending decreased * n RECENT. I'd like this, but I suspect this might > break something. > - Client could create a separate session to ask STATUS (RECENT) for the > selected mailbox. Kludgy. > - Client could re-SELECT the mailbox. Kludgy and expensive. > - Client could issue LIST for the current mailbox and check if it has > \Unmarked flag. > > LISTing would probably be the best thing to do, but if server shows > neither \Marked nor \Unmarked, it doesn't solve the problem. Luckily > it's not too bad - it's only for selected mailbox. > > Note that I don't consider any of these \Recent flag behaviour changes > to be non-compliant with current RFC, since it has this nice clause: > > If it is not possible to determine whether or not this > session is the first session to be notified about a message, > then that message SHOULD be considered recent. > > My server just doesn't happen to always know when the recent > notification was sent :) > > > -- > ----------------------------------------------------------------- > For information about this mailing list, and its archives, see: > http://www.washington.edu/imap/imap-list.html > ----------------------------------------------------------------- >
