- From: Cyrus Daboo <cyrus@daboo.name>
- Date: Wed, 14 Dec 2011 10:03:51 -0500
- To: andrew@morphoss.com
- cc: w3c-dist-auth@w3.org
Hi Andrew, --On December 14, 2011 8:29:13 PM +1300 Andrew McMillan <andrew@morphoss.com> wrote: > (1) invalid sync token error > > When I send a token which is invalid I receive an error response. This > is not particularly useful to me in my client. I (somehow) got an > invalid sync token - maybe it expired - but there's probably no useful > interaction with the user that I can take as a result. I just have to > fall back to a full re-sync. It seems to me that it would be more > useful to treat this case the same as if no sync token were supplied, > perhaps also supplying additional information that the sync token was > (expired|invalid|...) within the response. > > DAViCal was in fact doing this (without error information) until I > recently corrected the error. I would prefer to keep invalid vs no sync-token behavior separate. My rationale is that when an invalid token is presented, and the server is going to force the client to go back to a full sync, it is imperative that the client know that since it will either have to purge its current cache prior to a full sync, or treat the full sync results in a significantly different way than it would if it were an incremental sync. Now one way to achieve that would be as you describe, with the addition of some indication from the server that it fell back to a full sync so the client can change from incremental to full behavior. We don't have such an indication now, and I would be reluctant to add one. The other issue here is that a client may want to do full syncs differently from incremental. e.g., if the collection is known to be very large, the client may not want to get all the resource data in a single full sync response, instead opting to use the DAV:limit option to "batch" the full sync results. With your approach, the server would return the full set of data (unless the client had uses limit for incremental). Also, I know that CalDAV clients doing time-range based sync'ing have special logic that means they often don't use sync report for a full sync. At this point I prefer the two-step process as it gives clients the flexibility to choose how and when a full sync is initiated. I don't think it is all that big a burden on clients and the extra roundtrip is reasonable given that this is an edge case that should not occur very frequently. -- Cyrus Daboo
Received on Wednesday, 14 December 2011 15:06:46 UTC