W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2007

Re: [Ietf-carddav] Comments on draft-daboo-carddav-02

From: Cyrus Daboo <cyrus@daboo.name>
Date: Mon, 16 Jul 2007 13:50:23 -0400
To: Lisa Dusseault <lisa@osafoundation.org>, Julian Reschke <julian.reschke@gmx.de>
cc: "Mr. Demeanour" <mrdemeanour@jackpot.uk.net>, w3c-dist-auth@w3.org, ietf-carddav@osafoundation.org
Message-ID: <46E042B9969741D9649CA7BF@caldav.corp.apple.com>

Hi Lisa,

--On July 16, 2007 10:27:30 AM -0700 Lisa Dusseault 
<lisa@osafoundation.org> wrote:

>> Now wouldn't it be nice if a client could check for changed
>> resources *and* get their content in a single request? That seems
>> to be something obvious missing from the multiget report.
> I've worked on some synch stuff and it would be even nicer to make
> replication general, not specific to CalDAV.  So I agree, and I'm happy
> Cyrus is doing some work on that.

Yes its true that its nice to be able to do all that, and the 
synchronization report extension was designed to allow that with the 
extension of using the "pseudo" properties for at least CalDAV and CardDAV.

Note however, that clients may not always want to get the data. In fact 
that could be a bad thing to do if there have been lots of changes. Since 
the client has no control over the amount of information the server would 
return, and since resource bodies may be much larger than the set of 
properties otherwise asked for, this could be a big problem on limited 
capacity devices or over slow links.

What I would expect is that a client would use the sync. report to find the 
list of changed resources and then do a series of multigets to "page" 
through the changes and update its cache making sure that each response is 
likely to be within any resource constraints it might have. So I think 
there is a need for both the sync. and multiget reports as separate 
features. Of course we could combine all these into one, but then we might 
end up with one big monster...

Cyrus Daboo
Received on Monday, 16 July 2007 17:50:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC