Subject: Re: [VCARDDAV] new webdav sync draft

From: Helge Hess <[email-masked]>
Date: Sun, 6 Dec 2009 22:34:33 +0100

Hi,

Arnaud asked me on my opinion on the following ...

On 19.11.2009, at 18:20, Arnaud Quillaud wrote:
> I have just submitted a new version of the webdav sync draft (http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ).

=>
>    2.  Do clients really need to be notified that a resource was created
>        versus modified ?  They should be able to figure that out by
>        looking at the state of their current cache.  If this information
>        is not necessary, the response would not need to contain a DAV:
>        status along with the DAV:propstat.  This would allow the use of
>        a regular multistatus (simply extended with a sync-token
>        element).

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.

Greets,
  Helge

---

From: Arnaud Quillaud <[email-masked]>
Date: Mon, 07 Dec 2009 15:58:18 +0100

> 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]
Maximilian Odendahl who is working on the Symbian CalDAV connector gave 
us the same feedback.
And it looks like the Inverse Edition of Mozilla Lightning is doing the 
same thing (i.e. scan regardless of the status sent by the server).

Arnaud
> _______________________________________________
> caldav mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/caldav
>

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 07 Dec 2009 10:55:16 -0500

Hi Helge,

--On December 6, 2009 10:34:33 PM +0100 Helge Hess 
<[email-masked]> 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

---

From: Helge Hess <[email-masked]>
Date: Mon, 7 Dec 2009 21:43:16 +0100

On 07.12.2009, at 16:55, Cyrus Daboo wrote:
> 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.

Ah, OK. I would have expected a "deleted" and a "new" entry in such a case.

Now thinking about it, I think it might be an issue if a resource in the cache is replaced with an entirely new resource.
Eg the client might have (real world: is likely to have) extra client-side data which is only valid for the 'old' resource.

But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems.

> 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.

I think performance might be a real world issue with restricted clients (mobile) and large folders, where a key lookup does have a cost.

Anyways, I stick to my opinion, slightly extended: Either way is fine with me with a slight preference towards having a separate 'created' AND 'deleted'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it.

:-)

Greets,
  Helge

---

From: Julian Reschke <[email-masked]>
Date: Mon, 07 Dec 2009 22:57:45 +0100

> But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems.

It could if the server supports DAV:resourceid. (see 
draft-ietf-webdav-bind).

> ...

BR, Julian

---

From: Andrew McMillan <[email-masked]>
Date: Tue, 08 Dec 2009 11:26:06 +1300

On Mon, 2009-12-07 at 21:43 +0100, Helge Hess wrote:
> > 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.
> 

Yes, and in fact I revisited my code for this situation after reading
Cyrus' note and discovered that I had implemented that particular case
incorrectly in exactly that way.

Sending a DELETE followed by a CREATE in this situation would seem to
more clearly communicate the real-world action, and while there will be
times when the sync report simply ends up prompting the client to
perform a full sync, reducing the frequency of those situations should
also be a goal.

On the other hand if we consider this analogous to two consecutive
PROPFIND requests providing a difference of 'that resource is modified'
which clients must necessarily have to cope with already, then it would
be better to send a 'resource modified' in the sync response.

As it stands, it seems to me to be a gotcha and an inevitable a source
of bugs for any client side implementation which sees the create and
makes the easy assumption that it means no resource existed in a local
cache.

> Anyways, I stick to my opinion, slightly extended: Either way is fine
> with me with a slight preference towards having a separate 'created'
> AND 'deleted'. If that would be significantly more difficult for
> servers, lets drop it, if not, lets preserve it.

That does seem the safest approach.

Regards,
				Andrew McMillan.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
        Don't you wish you had more energy... or less ambition?
------------------------------------------------------------------------