Re: multiget reports Re: Thoughts on relation to WebDAV

This BATCH/multi-GET topic comes up quite regularly every year or so.  
It's a pony discussion.

For all use cases I have seen so far either
1. pipelining was adequate for it
2. or examples where as you described with optimizations for multiple  
operations (security checks, dbms lookup, etc.)

Case 2 could be betterh andled (e.g. without changing the worldwide  
HTTP implementation) by optimizing the URL namespace. What I mean is  
that one adds URLs to the application which represent specific views  
on multiple resources. Those you can then retrieve with a single GET.

Look how google does it. They have given the first 20 search results  
a single URL.

//Stefan

Am 28.05.2008 um 16:08 schrieb Cyrus Daboo:

>
> Hi Helge,
>
> --On May 28, 2008 11:14:09 AM +0200 Helge Hess  
> <helge.hess@opengroupware.org> wrote:
>
>> Its not a really good example because its not a hugely compliant  
>> WebDAV
>> server nor implemented that well, but the OpenGroupware.org ZideStore
>> serves iCal and vCard files via GroupDAV.
>> An individual GET with all the authentication, authorization and  
>> vCard
>> building takes ~50ms which hurts a lot when you retrieve 10.000  
>> records,
>> its ~8mins in the initial sync! We do a lot of caching etc to speed
>> things up, but still its pretty slow.
>> Now a multi-GET on moderatly sized batches takes almost the same  
>> time, eg
>> for 100 records its still ~70ms.
>>
>> I think thats the reason why CalDAV added those multiget REPORTs, on
>> request of RDBMS based server vendors.
>
> Well you don't need an RDBMS backed server to see the benefit. The  
> Apple CalDAV server uses flat files to store each calendar resource  
> plus an index in each calendar collection to optimize queries.  
> multiget is a big win for us. One of the biggest factors is being  
> able to aggregate the ACL check of all the resources. There are  
> several optimizations that can be done, and in the best case only  
> one privilege check is needed for all the resources being fetched.
>
> The other key thing to remember is that multiget allows the client  
> to fetch properties as well as data. i.e. its a combination of  
> multi-PROPFIND as well as multi-GET. Obviously DAV:getetag is the  
> one key property clients will fetch along with the data. That might  
> not be enough to fully justify this approach, but it does keep it  
> flexible.
>
> -- 
> Cyrus Daboo
>
>

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

Received on Thursday, 29 May 2008 07:42:20 UTC