Re: multiget reports Re: Thoughts on relation to WebDAV

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

Received on Wednesday, 28 May 2008 14:09:21 UTC