Andreas Aardal Hanssen writes:
I have probably misunderstood something about the wonderful world of untagged responses.
I think you've actually understood it too well. You've understood it so well that your beautiful and coherent design may not interoperate very well with the such-and-suches that pretend to be IMAP clients.

Speaking entirely personally, of course.

If the client does not get an unexpected untagged response when doing nothing, it will not drop all the data it has already, it just assumes that everything remains the way it was the last time it checked.
This sounds like an unsafe assumption. I agree it ideally should be like that, but it sounds as if you have too much faith in the clients.

So if a server suddenly says hey, FETCH (FLAGS..), the client will update itself. If the server does not, the client _keeps its state_. So much for the argument that the client should assume that the state of the message is undefined. If you didn't learn anything more about the message, then just assume it's unchanged.
Uh-huh. But in addition you need to send the "unnecessary" responses Mark mentioned, including the content-free FETCH response to STORE.

If the client asks for something twice, there may be a good reason for that. Usually there isn't, but there may be. For example, perhaps the client has an "empty cache" command that deletes all client-side data but doesn't close the IMAP connection(s).

--Arnt


Reply via email to