Re: multiget reports Re: Thoughts on relation to WebDAV

Geoffrey M Clemm <[email protected]>
Newsgroups gmane.ietf.webdav
Message-ID <OF99B92804.8F31F5E5-ON85257458.00498D28-85257458.00499583@us.ibm.com>
+1 for Stefan's comments.

Cheers,
Geoff

[email protected] 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 
> > <[email protected]> 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
> 
> 
> 
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.