On Thu, 8 Jan 2004, Christof Drescher wrote: > When testing with a couple of clients, I found that some do not really work > well with unsolicited server status updates, e.g. flag updates or an "* <n> > EXISTS" message.
Clients which do not handled unsolicited status updates are broken, as this is a requirement of IMAP. See RFC 3501, section 5.2. > E.g. Mulberry or PC-Pine (those I just tested) do simply ignore those > messages, and even worse, they are "lost" for the next noop (pine catches up > fine, but mulberry never gets it, only at re-login). I can't speak for Mulberry, but you are wrong about PC Pine. I wrote the IMAP code used by PC Pine. I can assure you that it handles unsolicited status updates. You are confused about PC Pine's behavior, and very likely are also confused about Mulberry's behavior. I think that what may be happening is that you are sending these updates when no command is in progress, and have not thoroughly grasped the implications of RFC 3501 section 5.3. Specifically, your comment that "Pine catches up fine" suggests that you think that all clients read responses immediately upon it being sent by the server. If that were the case, there would be no need for the flow control cautions in section 5.3; nor would there be any need for the IDLE command. Most clients only read from the server when they are in an server-response wait state, and typically only enter such a state after sending one or more IMAP commands. Often this is a blocking wait state. They leave this state when the tagged response(s) for the command(s) are returned. The IDLE command was designed with this in mind. If this is what's going on, then Pine most assuredly did *not* ignore the status update responses. It simply did not read them, and they remained in the TCP buffer until the next time Pine issued a command (any command). At that point, Pine went into a read state and at that point it read those status update responses. At worst case (an inactive Pine session), this may involve a delay of up to mail-check-interval seconds; this defaults to 150 so within 2.5 minutes. Note as well that defiance of the flow control cautions of section 5.3 will result in a deadlocked server. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
