Hi Larry, >Christof, as the author of the well-known server (there, I gave it >away), the "ghost" messages that it returns are valid w.r.t. FLAGS, but >when you attempt to fetch a body part, it returns NIL (or an envelope >containing only NILs) etc.
Arnt was arguing this might viloate cache semantics; a message which has been fetched before would return different content (albeit NIL content) than before, which should (or must?) not happen. Now one might argue if a client has fetched this data before, why should it do so again, which is mainly true. The only situation I could imagine this to be wrong is if a client fetches BODYSTRUCTURE data, receiving part sizes+lines, which would not be returned in the subsequent fetch of the expunged message then. >Our problem was that our message store doesn't have the ability for the >IMAP server to add a reference to a message when it hands the message >out to the IMAP clients, thus if another user using another client >[...] So I see you did not implement message persistenscy by implementation contraints, I did not by design. In any case, we both need a working solution conforming to the specs, right? >Btw, you were earlier objecting to maintaining per-client state of the >messages that have been given to the client, this is a flat-out >requirement of IMAP - the server MUST maintain a list that contains: >The messages that the client has been told about >The message sequence #s of those messages >The UIDs of those messages >The FLAGS for those messages (this is critical for read-only >mailboxes) Did I object? If I did so, please forgive (might been in the weird discussion about Recent? I learned there... :-) ). I see there are requirements for certain client-state information, especially flags, expunged state (which you go for with the "messages that the client has been told about"+msn+uid). But the last sentence still holds, though it has not yet been answered: >> So I could also live with these ghost messages. What about >> stating something like "ghost messages (as defined in >> RFC2180) are a valid response, which should force clients to >> NOOP to catchup". >> >> I just want clarification for the issue, be it a "NO >> [NOOPFIRST] Fetch response" >> or "valid NIL message response". Any comments would be appreciated... Christof
