Mark Crispin <[EMAIL PROTECTED]> wrote: > IMAP is *read-write*. Writes based upon damaged reads are -- by > definition -- creation of new damage.
Can you give a concrete example? I'm having a hard time imagining how this could happen. >> Further clobbering an already clobbered file would be bad, and it >> should not be possible to do it by accident, so a noisy warning and >> confirmation request would be in order if the user tries that. > > And exactly how is the server going to accomplish that? We were talking about a text editor at that point, not an IMAP server. You brought it up. Myself, I don't think the analogy is very good. > Think about what happens if the client author thinks like you do, > and tries to bluff through what should be "horrible error #69, must > crash" conditions. I still don't know exactly what constitutes "horrible error #69" in your mind. > perhaps you remember BSD UNIX on VAX, where references through a > null pointer would happily return 0. To me, that sounds a lot like an IMAP server that returns NIL values instead of a NO response in the case of a deleted (or otherwise inaccessible) message. > Haven't you encountered sysadmin who ignore your problem reports > because they assume that anything short of a complete failure must > be a user error? I don't think additional gratuitous failure is an appropriate response. >>>> Isn't it also reasonable to expect that things might change over time? ... > You implied that the way to handle errors will change over time so > as to force the client to know about a lot more things that should > be private to the server. I guess I was unclear. I meant that the state of the mailbox would change over time, and the server should accurately report the present state at any given time. paul
