Re: LIST and Marked folders - and a further suggestion.
On Mon, 2003-06-23 at 10:10, Richard Bang wrote: Hi, Just for my upended worth. My implementation will never return either /Marked or /Unmarked. This is because when I was testing with multiple concurrent connected clients (as I like to work) it screwed up the new message counts. I want to have 2+ client open at once (I have 4 PC's in different locations) I want to be able to see new mail on all of them without having to choose which one should take priority or have any of them ignore a mailbox just because I last looked at a folder with a different client. This is a bug in your clients, not in your server. They are making the flawed assumption that \Unmarked means they can skip the folder -- in fact it doesn't; it means nothing to the vast majority of clients -- those which care about \Seen not \Recent status. Here I disagree with Mark's statement that it's non-constructive to make absurd interpretations of the protocol in this mailing list. The interpretation that \Unmarked status gives you an excuse for skipping STATUS on the folder in question is absurd for most clients, yet it _is_ appropriate to discuss it here. When contemplating \Marked and \Unmarked flags, I saw a problem and asked about it... others evidently just went ahead and _used_ the \Unmarked flag even though it's completely irrelevant to them. It's _that_ behaviour which is non-constructive, surely? -- dwmw2
Re: LIST and Marked folders - and a further suggestion.
On Mon, Jun 23, 2003 at 10:10:59AM +0100, Richard Bang wrote: A new command set MONITOR and UNMONITOR would solve this as it would allow my client to be notified of any mailbox it were interested in. I've suggested similiar commands before.. And Mark was also planning some new mail notification. Anyway, I think the nicest way to do this would be to tell server to send standard untagged STATUS replies for specified folders. Or server could do that by itself always if it doesn't cause extra trouble for it. Only problem would be to make clients realize they don't have to poll for STATUS if server decides to send it automatically. Getting notified of some flag changes (custom flags especially) could be useful as well but I'm not sure how that'd work. Didn't status-counters extension support that? STATUS notification could be enough with it then. Configuring this thing could be done with ANNOTATEMORE extension.
Re: LIST and Marked folders - and a further suggestion.
On Mon, 23 Jun 2003, Richard Bang wrote: Just for my upended worth. My implementation will never return either /Marked or /Unmarked. I see. Do you believe that deliberately thumbing your nose at the protocol, as you say you will do, is the way to build interoperability or create quality software? This is the sort of bad behavior that Microsoft is accused of doing. This is because when I was testing with multiple concurrent connected clients (as I like to work) it screwed up the new message counts. So, you tested with a buggy client, and concluded that because of that client's bug, you should create a bug in your own server. If the definition of the protocol tells a client that it can ignore a mailbox simply because a different client saw the mailbox then there is a problem with the protocol. It is a remarkably bad idea to half-listen to a discussion, pick up on a single phrase, and jump to conclusions based upon that phrase. You completely misunderstood what was being discussed. I am willing to explain it to you *if* you will give me the courtesy of listening. Will you listen? It would be nice if there were a way to monitor a none selected mailbox for flag changes and message arrivals. There is work in progress on that vein. It does not expedite new facilities when wars have to be fought on existing facilities. Do the existing facilities according to specification. Do not inflict yet another non-interoperable server implementation on the world. I realise these don't really apply to something like pine, but to be honest if I had to use pine as my mail client I would probably give up using email :-) You probably have never used Pine, which probably explains why you made your comments. You are not on a path that will lead you towards producing a good quality IMAP server. It would be prudent for you to reconsider some of your decisions. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: LIST and Marked folders - and a further suggestion.
On Mon, 2003-06-23 at 17:03, Mark Crispin wrote: On Mon, 23 Jun 2003, David Woodhouse wrote: others evidently just went ahead and _used_ the \Unmarked flag even though it's completely irrelevant to them. How did you arrive at that conclusion? What others used \Unmarked without understanding what it means? My 'others' I mean the authors of the clients which Richard tested prior to saying, in the paragraph which I quoted in my own reply, This is because when I was testing with multiple concurrent connected clients (as I like to work) it screwed up the new message counts. Perhaps I misinterpreted him, and his 'multiple concurrent connected clients' was in fact just multiple copies of the _same_ client, and hence there was only _one_ such buggy client. Given the ease with which this particular mistake can be made, however, I suspect the plural is correct. -- dwmw2
Re: LIST and Marked folders - and a further suggestion.
On Mon, 2003-06-23 at 19:11, Mark Crispin wrote: Anyway, I think the nicest way to do this would be to tell server to send standard untagged STATUS replies for specified folders. That would be very expensive with some mail stores. STATUS requires values that *may* be in mailbox metadata but may also require a costly calculation. I know. 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. 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). Even if mail store can't support any shortcuts, it's still no worse than letting the client do the polling. 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. I wouldn't really mind if the STATUS checking stopped after it noticed the first new mail. The STATUS checks should start again when _any_ client selects the mailbox (which might be tricky).
Re: LIST and Marked folders - and a further suggestion.
On Mon, 23 Jun 2003, Timo Sirainen wrote: If you also send notifications for some client selected mailbox xyz, that could be used to reset the contains new mail flag. I think that would make it pretty much usable. You already have that ability: that's what \Marked and \Unmarked do! \Marked gets set when new mail happens, and \Unmarked gets set when some client selects the mailbox. The complaint was that this effectively reflects \Recent status as opposed to not \Seen status. Your suggestion has the same flaw. What you want, I think, is some kind of notification for a message that did not have \Seen status just had \Seen applied, and all messages now have \Seen status. :-) That is the beauty of using recent. It solves the 98% case. The other 2% is very complicated to solve. Don't forget, if you consider new to be not seen, then that means that if a user reads his mail, decides not to read a particular message at that time, and then opens his mail the next day, he has new mail even if no further messages arrived between that time. I would be very much annoyed if I was continually harassed about a new message which I specifically choose to defer reading until later. IMAP considers a message to be new only if it is both recent and unread, and recognizes a separate concept of an unread message which is no longer new. The fact that a particular client may not choose to present this is not a reason to declare recent/marked/unmarked useless, and is especially not a reason for a server to deliberately sabotage this IMAP facility. We already have the deplorable example of servers which respond NO to SEARCH commands. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: LIST and Marked folders - and a further suggestion.
On Mon, 23 Jun 2003, Timo Sirainen wrote: Or actually .. UW-IMAP + mbox seems to set mailbox \Unmarked even if I do only STATUS for it. That wouldn't work well. Is it even RFC-compliant? :) What version? What host operating system? If UW imapd does that, then it is a bug and I will fix it. I can't reproduce that problem on my test system, so it's probably yet another case of something that depends upon the underlying UNIX variant. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: LIST and Marked folders - and a further suggestion.
On Mon, 2003-06-23 at 23:58, Mark Crispin wrote: On Mon, 23 Jun 2003, Timo Sirainen wrote: Or actually .. UW-IMAP + mbox seems to set mailbox \Unmarked even if I do only STATUS for it. That wouldn't work well. Is it even RFC-compliant? :) What version? Tested with 2003.337 and 2002c. What host operating system? Linux and XFS filesystem. If UW imapd does that, then it is a bug and I will fix it. I can't reproduce that problem on my test system, so it's probably yet another case of something that depends upon the underlying UNIX variant. I thought \Marked == atime mtime, \Unmarked == atime = mtime? STATUS opens the mbox file which updates atime, so how could it even work? You could fix it with utime() but that'd be ugly and racy. % printf 'x list mail/foo\nx status mail/foo (messages)\nx list mail/foo\n'|~/src/imap-2002c/imapd/imapd * PREAUTH [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS BINARY SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] Pre-authenticated user cras hurina IMAP4rev1 2003.337 at Tue, 24 Jun 2003 00:24:16 +0300 (EEST) * LIST (\NoInferiors \Marked) / mail/foo x OK LIST completed * STATUS mail/foo (MESSAGES 4) x OK STATUS completed * LIST (\NoInferiors \UnMarked) / mail/foo x OK LIST completed
Re: LIST and Marked folders - and a further suggestion.
On Mon, 24 Jun 2003, Timo Sirainen wrote: I thought \Marked == atime mtime, \Unmarked == atime = mtime? STATUS opens the mbox file which updates atime, so how could it even work? You could fix it with utime() but that'd be ugly and racy. Surprise. There is quite a bit of such ugliness specifically for that purpose. Don't trust the stat man page for information on the conditions that update atime and mtime. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
