On Thu, 2009-12-17 at 11:29 -0800, Mark Crispin wrote: > On Thu, 17 Dec 2009, Timo Sirainen wrote: > > On Thu, 2009-12-17 at 10:22 -0800, Mark Crispin wrote: > >> No server "caches the flags" as you describe. If the mail store in the > >> server supports multiple simultaneous sessions to the same mailbox (e.g., > >> mix and mbx formats in UW), then flags are updated immediately. > > Well, not necessarily immediately, at least not all servers. A NOOP > > command should refresh flags and other things with most servers. > > A server that requires use of the NOOP command to synchronize is broken.
Sure, but there are such servers. For example Cyrus. Actually in Cyrus it seems to work in a rather weird way: session 1: 1 store * +flags \seen (session 2 won't see this change, no matter what it does.) session 1: 2 noop (session 2 still won't see the change with fetch flags.) session 2: 3 noop (now session 2 finally gets the untagged FETCH FLAGS reply.) > A client that uses the IDLE command has no reason to use the NOOP command, > ever. Yes, IDLE and NOOP are the commonly working ways. With the above Cyrus example session 2 could have been IDLEing instead of doing a NOOP. > > Hmm. Dovecot's current behavior is that doing a FETCH FLAGS just after > > its flags had changed in another session first returns one FETCH FLAGS > > with the old flags (the FETCH reply), then another FETCH FLAGS with the > > updated flags (after it noticed the changes). > > That's OK. It's in the same set of responses, isn't it? The later flags > response overrides the former one. Right. I changed it anyway, maybe it'll help some poorly implemented client.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
