Mark Crispin <[EMAIL PROTECTED]> wrote: > On Wed, 24 Mar 2004, Paul Jarc wrote: >> Can you give a concrete example? I'm having a hard time imagining how >> this could happen. > > Download-and-delete. A single message couldn't be accessed because of a > protection failure, but it was quite deleteable.
If the client deletes a message it wasn't able to download, then that sounds like a buggy client. > If we have learned anything in the past several years, it is that > the imagination of programmers as to what can go wrong in such > circumstances is far more limited than the possibilities of what > will go wrong (and what can be exploited). That's exactly why I prefer the simle tactic of reporting any errors when they happen. > Some piece of data in the editor disappears unexpectedly. Do we continue > editing the rest of the file as if nothing happened? We notify the user, give them advice, and let them choose. >> I still don't know exactly what constitutes "horrible error #69" in >> your mind. > > We've been taking about a message which disappeared unexpectedly and outside > of the scope of the protocol. Or within the scope of the protocol, by another client. Is that horrible? > Nope. NIL is a defined value, with defined semantics. Refer to the syntax > rules in RFC 3501. There are many many things (even in quite well populated > messages) that can be NIL with well-stated rules of what that means. Right - and where do those rules include the meaing "this message is no longer present"? Where do they include the possibility of a data item formerly being non-NIL, but later becoming NIL? > A null pointer is analogous to NO, which means that the value is undefined. Right. NO is NULL; NIL is 0. I don't like NIL for a missing message, for the same reason that we don't like *NULL==0. A client may have local storage of some messages. In the case of a shared mailbox, the user might want to retain some messages even if another user deletes them from the IMAP mailbox. But if the server returns NIL, that may overwrite the local previously-stored message. This is similar to your download-and-delete example, but the difference is that with NO, the lossage is the client's fault; with NIL, it's the server's fault. > Due to a server bug, the server entered a state that it never should > have entered, and since IMAP does not express that state the server > has to crash. I don't consider concurrent deletion to be a bug, or an unreasonable state. The protocol is expressive enough to allow it to happen, even though the server can't be entirely specific about what has happened. paul
