On Wed, 12 Mar 2003, Eric A. Hall wrote: > > I'm going to assume you meant something sane when you said <time>, of > > course :) > > Uh, heh, I meant time alright. Specifically have the server return a > timestamp whenever a folder is closed, and let the client cache it.
We're digressing somewhat. Yes the idea is basically sound but time actually isn't guaranteed to actually be different _every_ time you query it, and in the presence of NTP etc., isn't actually guaranteed to be monotonic either. Plus as son as you start _calling_ it 'time' you get people wanting to use the clock on the _client_ and that's obviously even more broken. Take a timestamp, make sure it's always newer than the previous one, and call it something different :) > > The protocol side could be fairly simple -- the idea that Timo Sirainen > > offered in <[EMAIL PROTECTED]> seems fairly close to > > what we'd want. You'd declare that a server supporting FLAGS-VALIDITY > > _MUST_ include any messages with changed flags in its response, and > > SHOULD make an effort not to include messages _without_ changed flags. > > Doesn't this require the server to cache client state? It'd be a lot > simpler for the clients to keep track of their own state, since that's > what they're already doing. It doesn't require any per-client state on the server. For each change made to the folder, the server advances through a sequence of cookies (which might by an amazing coincidence resemble timestamps) and hands one off to the client. Each client remembers the cookie which was given to match its own locally-cached information. Then occasionally a client comes along to the server and says "Tell me what, if anything, changed since $THEN". The server has the _option_ of maintaining some details about what changed and when, for the last few changes which were made to the folder. If the cookie the client presents is so old that the server's forgotten everything that happened since then, then the server can just tell the client to invalidate its whole cache. If the server isn't keeping any logs at all, this just becomes a simple compare of the cookie with the 'latest' cookie, and a yes/no answer. Even that most simple implementation will suffice to optimise the common case where no changes have been made by another client in the time since this particular client last looked at the folder. (Of course you ensure that in the one-client case you don't trigger invalidates when they're not necessary. So new mail arriving shouldn't change the change-counter cookie, only changing of flags on _existing_ mail should do that. And when a client changes flags in a folder and the change-counter cookie advances, that client shouldn't be told to invalidate its cache if it was already up-to-date. But those are just details.) -- dwmw2
