"Richard Bang" <[EMAIL PROTECTED]> writes: >When a client is inactive it can get unsolicited responses, flag changes >, exists, expunge etc.
EXPUNGE responses cannot be sent by a compliant server when no command is in process. They can only be sent when it is not possible for a compliant client to send a FETCH, STORE, or SEARCH command; i.e., before the tagged response to a command other than FETCH, STORE, or SEARCH. c.f., rfc3501, sections 5.3 and 5.5. >According to what I read, if a client does a search and then does >nothing for 45 minutes, the server CANNOT send any expunge messages >because it does not know if the next command MIGHT be a fetch. Correct. The IDLE extension provides a means for a client to request updates (including EXPUNGEs) at these times. >Is this really correct, should I only send unsolicited after a command. >In which case, you lose all ability to synchronise clients because of >the command sequence. I don't understand what you mean by "lose all ability to synchronise clients". >As my server stands ATM I can have four clients connected and they all >remain perfectly in sync. However, if I have to start predicting what >the client will do and holding data back indefinably this will result in >all sorts of a mess. "Indefinably"? The server will send it after the next command that permits it, as specified by the rfc. >Surly, rather than having a situation where the server has to remember >the state of each client, there should be a server response that tells >the client that its data may be out of sync. (I think you means "surely" instead of "surly") If the client->server protocol involves data in need of synchronization, such as IMAP msgnos do, then the protocol must provide periods during which those values are stable or else it's impossible to guarantee that a client will ever make forward progress. A client at the end of a slow or long link might always complete resynchronization, only to have its next command provoke an "out of sync" error. Such a protocol would therefore be unusable over the Internet with 'busy' mailboxes. Philip Guenther [EMAIL PROTECTED]
