- From: Helge Hess <helge.hess@opengroupware.org>
- Date: Mon, 7 Dec 2009 21:43:16 +0100
- To: Cyrus Daboo <cyrus@daboo.name>
- Cc: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>, caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org
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
Received on Monday, 7 December 2009 20:43:49 UTC