Re: [caldav] new webdav sync draft

Arnaud Quillaud <Arnaud.Quillaud@Sun.COM> Mon, 07 December 2009 14:58 UTC

Return-Path: <Arnaud.Quillaud@Sun.COM>
X-Original-To: caldav@core3.amsl.com
Delivered-To: caldav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC9123A6806; Mon, 7 Dec 2009 06:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.619
X-Spam-Level:
X-Spam-Status: No, score=-5.619 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFVJHaQfyt-z; Mon, 7 Dec 2009 06:58:48 -0800 (PST)
Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 90DE03A67FB; Mon, 7 Dec 2009 06:58:48 -0800 (PST)
Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB7EwaR7013792; Mon, 7 Dec 2009 14:58:36 GMT
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_rUL4U2HZ1yHgNIdCVZietw)"
Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KUA00300CXB5T00@fe-emea-09.sun.com>; Mon, 07 Dec 2009 14:58:29 +0000 (GMT)
Received: from arnaud-quillauds-mac-mini.local ([unknown] [129.150.117.219]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KUA00GVBEX7XA70@fe-emea-09.sun.com>; Mon, 07 Dec 2009 14:58:20 +0000 (GMT)
Date: Mon, 07 Dec 2009 15:58:18 +0100
From: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>
In-reply-to: <FC4CE9C0-0F2C-4F4A-8F22-DAE3F1AA6B4D@opengroupware.org>
Sender: Arnaud.Quillaud@Sun.COM
To: Helge Hess <helge.hess@opengroupware.org>
Message-id: <4B1D180A.2050103@sun.com>
References: <4B057E6B.7040808@sun.com> <FC4CE9C0-0F2C-4F4A-8F22-DAE3F1AA6B4D@opengroupware.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2
Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org
Subject: Re: [caldav] new webdav sync draft
X-BeenThere: caldav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <caldav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/caldav>
List-Post: <mailto:caldav@ietf.org>
List-Help: <mailto:caldav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2009 14:58:49 -0000

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
>