On Wed, 9 Oct 2002 09:42:54 -0700, Larry Osterman wrote: > If the IMAP for some mail stores defers committing operations until a > logout command, how does the server report the result back to the > client? The client at this point has no way of recovering from the > error, since it's tearing down the connection - just like an OS close() > call, a LOGOUT cannot realistically fail.
I said "a checkpoint", not "a LOGOUT". LOGOUT is one of many things that does a checkpoint. There is an implicit presumption that in a defer-type mail store, the eventual "commit" operation is guaranteed to succeed. This is a more or less safe presumption. It has to be, since otherise defer-type mail stores can't work at all. Basically, disconnecting without issuing a proper LOGOUT is "tempting fate". The LOGOUT negotiation is a safety mechanism which ensures client/server agreement on disconnect and appropriate cleanup at both ends. Multiple redundant safety mechanisms may seem silly or unnecessary. That is, until the time that a failure occurs, and the safety mechanism which you deliberately disregarded was the only one left that could have saved you. I do not understand the argument about SEARCH. Short of a network failure, I have never seen a SEARCH be so slow that a wait for the result is intolerable. Furthermore, if a mailbox is so large that a SEARCH requires a noticable amount of real time, it seems to me that a well-written client would not want to blithely discard the hard-won state from a selected stream on that mailbox.
