on 3/12/2003 2:42 AM David Woodhouse wrote: > On Wed, 2003-03-12 at 06:58, Eric A. Hall wrote: > >>I'm not trying to start a religious war here, but how much work would it >>really be to have a protocol extension which allowed the client to request >>flags which have changed since <time>. It seems that all of the difficulty >>would be in the implementation (the server data-store), not in the >>protocol, and there would be significant benefits to having this option >>available in the protocol. Faster resynchronization between sessions would >>be very good for all clients, online and offline alike. > > 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. On reconnect, the client can just ask for all messages with a modification timestamp later than the last-cached value for that folder. For rich data-stores, this just requires a last-modified-on attribute for each message record; return those records which have a last-modified-on value greater than the requested value. > 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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
