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
-----------------------------------------------------------------
