W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2011

Re: WebDAV sync last call

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
Message-ID: <6D974159022CAA5DEA5FC072@caldav.corp.apple.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 14 December 2011 15:06:48 GMT