Hi Cyrus, On Mon, 27 Jan 2003, Cyrus Daboo wrote: >Hi Andreas, >--On Monday, January 27, 2003 7:36 PM +0100 Andreas Aardal Hanssen ><[EMAIL PROTECTED]> wrote: >|> What version of cyrus are you running? >|> Against our 2.1.11 server I have: >|> x store 1 flags () >|> * 1 FETCH (FLAGS ()) >|> x OK Completed >| OT, but why does the server return the FETCH update when no change has >| been made to the flags? >How do you know a change hasn't been made in the above example? There is no >way to tell what the state of the flags were before the command was issued >- some of them may well have been on, so setting flags to the empty set >would have turned those off and rightly resulted in the untagged response.
I have probably misunderstood something about the wonderful world of untagged responses. My whole interpretation was that many of these responses, typically FETCH, can show up in most occasions, even when the client does not ask for it, and that they are there to update the client. Some places the responses are required, or rather _expected_. Other times, the responses can be quite unnecessary. This is, to me, quite inconsistent in the protocol. If the protocol stated once and for all that all untagged responses are optional, and only necessary if they show updates, _pending updates_, to the state of the selected mailbox, then I'd be content. Now. 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. 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. The presence of an untagged EXPUNGE will tell you when the message was expunged. So if a client goes hey, STORE +FLAGS (), then the server can say well, you certainly didn't change the state of that message, so I won't bother giving you any updates either. After all - the info that the server gives when no flags have changed will often be totally irrelevant for the client. Ok - the client now knows that "the flags, by the way, are _still_ like this: (\Seen)". The server doesn't have to check wether the client has gone "FETCH FLAGS" - it can just assume that if the client wants flags then it will probably have done that fetch flags command already. If the flags were changed, I find it perfectly logical for the server to give that FETCH (FLAGS..) response. If the server _couldn't change_ the flags, I still find it logical. But if the server was asked to perform _no flag operation_ on a message, then why would the IMAP server want to waste the bandwidth? Finally, if someone can tell me where in the protocol it says that if the STORE command does _not_ give an untagged response, then the state of the _flags_ is _undefined_, then I'll stick a broom in it. :-) Andy -- Andreas Aardal Hanssen - Binc IMAP http://www.bincimap.andreas.hanssen.name/
