[GroupDAV] multiget

Helge Hess groupdav@opengroupware.org
Wed, 17 Oct 2007 03:59:48 +0200


Hi,

I'm still working on that GroupDAV(/CalDAV) Outlook message store  
provider and I wonder what we should do about multiget.
The OGo connector currently uses a dirty and quite specific hack to  
do this (special /Folder/_range_ID_ID_ID_ID collection URL).


By 'multiget' I mean retrieving multiple resources with a single HTTP  
request. Currently when syncing a new folder which contains 1000  
items with GroupDAV a client needs to issue 1000 individual GET  
requests, which of course isn't exactly perfect (though with proper  
caching its usually just a one-time issue - for the initial sync].

So, do we want to add multiget to GroupDAV?
If so, how do we want to add multiget?


Part of the problem is that there seems to be no "standard" HTTP way  
to get multiple resources in one step. CalDAV defines an own multiget  
REPORT for this, but this only works on iCalendar entities.


I tend to suggest that we should add an OPTIONAL multiget (if the  
call to multiget fails 501, individual GETs are to be issued by the  
client).


Further I think that we should probably specify a single, specific  
CalDAV:multiget REPORT, probably this one (CalDAV 7.9.1.):
---snip---
    <?xml version="1.0" encoding="utf-8" ?>
    <C:calendar-multiget xmlns:D="DAV:"
                         xmlns:C="urn:ietf:params:xml:ns:caldav">
      <D:prop>
        <D:getetag/>
        <C:calendar-data/>
      </D:prop>
      <D:href>/bernard/work/abcd1.ics</D:href>
      <D:href>/bernard/work/mtg1.ics</D:href>
    </C:calendar-multiget>
---snap---
Same thing for vCards as the CARDDAV:multiget.

We would leave out arbitary property combinations (either WebDAV or  
Versit) and only use "hardcoded" report (eg etag+caldata).
If a collection contains vCard *and* iCal entities, the client would  
need to send two REPORTs (and retrieve other stuff via GET).


Another option would be to specify a special POST URL for a  
collection, eg: '/Calendar/groupdav-multiget'. The thing I dislike  
about it is that this sits "on top" of HTTP (and mixes with the  
collections namespace).
But the obvious advantage is that its rather trivial to implement in  
the server (eg using a Perl script in Apache). And even for clients  
its easy to detect whether such a URL exists or not (404).


What do you think?

Thanks,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/