Re: multiget reports Re: Thoughts on relation to WebDAV

+1 for Stefan's comments.

Cheers,
Geoff

w3c-dist-auth-request@w3.org wrote on 05/29/2008 03:41:23 AM:

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