Re: multiget reports Re: Thoughts on relation to WebDAV

Hi Julian,

--On May 29, 2008 12:10:24 PM +0200 Julian Reschke <[email protected]> 
wrote:

>> 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