Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called HIGHESTMODSEQ in the document. The functionality you propose can be build as a small extension to CONDSTORE (and yes, other people already proposed something similar before).
David Woodhouse wrote: > 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.) Regards, Alexey __________________________________________ R & D, ACI Worldwide/MessagingDirect Watford, UK Work Phone: +44 1923 81 2877 Home Page: http://orthanc.ab.ca/mel I speak for myself only, not for my employer. __________________________________________
