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