Paul, if you haven't already done so, please download the complete archives of this mailing list and read them front to back. Yes, it will take several hours, but the experience of seeing this same argument about EXPUNGE and FETCH repeat over and over with no new points may be enlightening. Or depressing.
[EMAIL PROTECTED] (Paul Jarc) writes: >Pawel Salek <[EMAIL PROTECTED]> wrote: ... >I don't think it's helpful to hide [basic, unpreventable OS errors] nor >to design protocols that make it difficult to report them. I agree that servers shouldn't try to flounder on when something basic has failed. If the error has broken the IMAP abstraction such that some guarantee that the protocol provides to clients is no longer true, then the server should report the error (as a human readable description) to the client and close the connection rather than let the client continue to operate with an incorrect assumption. ... >> I think OK is better because NO is likely to pop up an error message >> on a situation which is not an error but just an shared expunge. You >> do want to get a pop up on failed imap operations, don't you? > >Sure. And if the client requests a message that was just deleted by >another client, then it makes sense to me that the user should be >notified. The overwhelming vote of support personal is to *NOT* do that. Guess whose vote counts when deciding what software to install. ... >> but I can imagine that some servers may have choose to expunge ASAP >> for, say, confidentiality reasons. > >Even ignoring confidentiality, it still makes sense to remove the >messages immediately for the sake of being honest to the client that >sent EXPUNGE. Since the IMAP rfc doesn't guarantee that expunging a message will make it unavailable to concurrent sessions (how could it when they could be in the middle of sending buffered data), a client has no reason to expect such behavior. It isn't honesty to tell the client something it has no reason to expect. It appears your real disagreement is with the IMAP mailbox abstraction with its guarantee that messages won't randomly disappear beneath a client. Well, even Marc agrees with you that a _next_ mailbox access protocol shouldn't do that (mainly because its so contentious), but it's a couple decades too late to change that in IMAP. It's funny: POP3 servers have managed to get by for years, sometimes going to great effort to make sure that once they have the mailbox open the messages in it won't just vanish, and then synchronizing carefully with the 'real' mailbox on QUIT. I don't recall much noise then about how hard it is to do that. Similarly, UNIX vendors have managed to guarantee that file contents won't vanish underneath an open filedescriptor just because the last link to the file has been removed. Why does this generate so much smoke for IMAP? Philip Guenther [EMAIL PROTECTED]
