[GroupDAV] multiget

[Chris Bryant]

Helge,

I think a multiget capability would be good to add, but we should keep it 
optional.  If it fails, the client can revert back to individual GETs.

I like the idea of using the "CALDAV: calendar-multiget" and "CARDAV: 
addressbook-multiget" requests like you suggested below.  I agree that we 
should keep it simple and support only the 'getetag' and 
'calendar-data/addressbook-data' properties.  Clients should not be allowed 
to specify which attributes within the calendar-data/addressbook-data should 
be returned.  I'm not a fan of caldav/cardav, but I would think implementing 
this one report should be simple to implement in most GroupDAV servers and 
clients.

GroupDAV doesn't currently include anything for handling Notes or Journals. 
If we add either of those (which would be nice if you are really working on 
an Outlook GroupDAV message store, since Outlook has Notes), would we be 
able to extend this to those?  It would actually be nice if we had something 
more generic, like "GROUPDAV: multiget" that could work for any type of 
object...

Chris


----- Original Message ----- 
From: "Helge Hess" <helge.hess@opengroupware.org>
To: <groupdav@opengroupware.org>
Sent: Tuesday, October 16, 2007 9:59 PM
Subject: [GroupDAV] multiget


> 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/
>
> -- 
> GroupDAV
> groupdav@opengroupware.org
> http://mail.opengroupware.org/mailman/listinfo/groupdav
>
>
>
>