On Tue, 2003-03-11 at 17:30, Timo Sirainen wrote: > That could be fixed by sending all the STATUS queries to server at once.
That's not really going to help. If I send all the STATUS queries to the server at once, it'll go off and ignore me for a while, while it does them all for me. It could be alleviated somewhat by ensuring that my client doesn't let background STATUS updates take priority over _real_ stuff I've asked it to do for me in the foreground like displaying mail messages -- but I still have a philosophical objection to the fact that I'm required to poll for status in folders which the server _knows_ haven't changed :) > Actually this brings to my mind: STATUS for selected folder isn't considered > good behaviour. Fetching flags for all messages in folder isn't considered > good behaviour. So, how exactly do I keep unseen messages count up to date > for selected mailbox? 000 SEARCH UNSEEN * SEARCH 800 801 000 OK [FLAGS-VALIDITY 123] SEARCH DONE 001 FETCH 800:801 (FLAGS) * 800 FETCH (FLAGS ()) * 801 FETCH (FLAGS ()) 001 OK [FLAGS-VALIDITY 123] You don't _need_ to keep flags for all messages, only those you care about. Which in most cases does happens to include unseen messages. > I wouldn't be against flags-validity, but I'm not sure if it's worth the > trouble. The kind of validity-request uidset-response would allow servers to > be pretty flexible in how they handle it. I think it should work something > like this: > > Client remembers the last flags-validity given by server and requests that > the next time it selects the mailbox. Server updates the validity when one > of the clients closes the mailbox and there has been at least one flag > update. It sends to all clients (including the one that is closing the > mailbox/connection): > > * OK [FLAGS-VALIDITY <newvalidity>] > > Updating flags-validity isn't necessarily a fast operation, so that way it > doesn't have to be updated all the time. > > Some ways for server to handle this: > > - Keep flags-validity value of last flag change for each message. Takes > pretty much disk space and may be slow. > - Keep only the last flags-validity value. That helps only when there hasn't > been any flag changes since client last accessed the mailbox > - Keep low-validity and low-uid. if client request any flags-validity >= > low-validity, only return low-uid:* instead of 1:* > - Keep a log of the last few flags-validities and what messages they changed Yep, that's basically what I was thinking. The server's options range from a simple change counter and telling the clients to invalidate _all_ cached flags if that changes, to far more sophisticated optimisations of the invalidation list. Note that you probably don't want to update the flags-validity token when new messages arrive. There are other ways of dealing with new messages anyway. You only change flags-validity when flags of an _existing_ message have changed. And we need to make sure that when there's only one client and it makes changes, it doesn't get told to invalidate its cache even by the most naïve server. Maybe we pass a flags-validity argument with the STORE command too or something? -- dwmw2
