Re: [caldav] new webdav sync draft

[Cyrus Daboo <[e-mail]>]

Hi Helge,

--On December 6, 2009 10:34:33 PM +0100 Helge Hess 
<[e-mail]> wrote:

> Its not crucial, but helpful. If I don't know that a resource is new, I
> obviously have to scan the cache to check for that. Which is
> significantly more expensive than a simple INSERT (status = 'N', url=abc)
> ... Given that WebDAV sync is supposed to improve sync with large
> folders, the 'check' time consumption becomes more relevant too ...
>
> The question is whether I would do the scan anyways, just to be sure
> there are no DUPs. Probably! :-) [either me, or a database unique
> constraint doing effectively the same thing]
>
> So I guess either way is fine with me with a slight preference towards
> having a separate 'created'. If that would be significantly more
> difficult for servers, lets drop it, if not, lets preserve it.

Just to clarify - right now the spec says that a resource that is deleted 
and re-created is reported as "new" if a sync-token prior to the deletion 
is given in the REPORT. In that case, were you to do an INSERT using the 
UID as a unique key for that reported item you would get an error as the 
client already has the old copy cached. So a "simple" INSERT isn't going to 
work in that case.

Now we could change that behavior to have the deleted/re-created resource 
reported as "modified" rather than "new". However, I think the reality is 
that clients are going to have to accept the fact that there may be false 
positives (though hopefully never false negatives) so the prudent thing to 
do is always do a proper match between the server reported results and the 
full cache they currently have. Maybe we need a statement clarify that.

-- 
Cyrus Daboo