W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2008

Re: multiget reports Re: Thoughts on relation to WebDAV

From: Cyrus Daboo <cyrus@daboo.name>
Date: Thu, 29 May 2008 12:29:00 -0400
To: Julian Reschke <julian.reschke@gmx.de>, Helge Hess <helge.hess@opengroupware.org>
cc: WebDAV <w3c-dist-auth@w3.org>, vcarddav@ietf.org
Message-ID: <77A3498B7242B3A47DDC8359@caldav.corp.apple.com>

Hi Julian,

--On May 29, 2008 12:10:24 PM +0200 Julian Reschke <julian.reschke@gmx.de> 

>> cache the contained, individual contents. In fact for the latter a BATCH
>> looks to be optimal, since the actual content caching is exactly the
>> same like for individual contents, whereas a REPORT needs custom
>> infrastructure.
> The assumption seems to be: we need multi-GET because of initial sync,
> and thus, if we have it, we'll use it for everything.
> Another approach would be to have a special GETtable resource that can be
> used for the initial sync, and then use regular, conditional GET requests
> for everything else....

But I think that will end up looking exactly like multiget for the most 
part. Some things to note: clients will typically need to use several 
multigets for the initial sync if the collection is large. I believe iCal 
broke down multigets into 50 or 100 resource fetches at a time. Our server 
won't allow more than 1000 to be returned in a report. So your special GET 
will need to have a way to select which ranges to fetch (just as multiget 
does) and it will need a way to expose, at the very least, the getetag 
property of each of those (again multiget can do that but also allows more 
properties to be returned). So I think you just end up with pretty much the 
same feature set.

Cyrus Daboo
Received on Thursday, 29 May 2008 16:29:43 UTC

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