- From: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>
- Date: Mon, 07 Dec 2009 15:58:18 +0100
- To: Helge Hess <helge.hess@opengroupware.org>
- Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org
- Message-id: <4B1D180A.2050103@sun.com>
On 6/12/09 22:34, Helge Hess wrote: > 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] > 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 > 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 > > > > _______________________________________________ > caldav mailing list > caldav@ietf.org > https://www.ietf.org/mailman/listinfo/caldav >
Received on Monday, 7 December 2009 14:59:12 UTC