[cosmo-dev] RFC4791 HTTP REPORT and Cosmo
sam.halliday at gmail.com
Sat Aug 23 12:05:47 PDT 2008
Argh... I also just realised that Google Calendar doesn't support the
REPORT method on the user's principal. How is iCal finding all my
calendars? Is there another, simpler way to list a user's calendars,
given their principal URL?
On 23 Aug 2008, at 19:57, Sam Halliday wrote:
> I am now able to get the list of VTODOs if I aim the request at a
> specific collection URL (using Depth 1), however the RFC does not
> make it clear how to perform VTODO requests for all collections, is
> that even possible? Also, is it possible to obtain the list of
> collections from the principal rather than the calendar-home-set...
> for a mobile device, every query results in a latency so 2 queries
> to get the list of the collections is a pain, and you don't even
> have their names at that point!
> Does anybody know of any more friendly descriptions of the protocol,
> perhaps with synchronisation examples and worldly advice? Some
> things I expect to need to know include:-
> - requesting that all calendar items use the GMT timezone (I'd like
> to handl TZs locally)
> - synchronising an edited offline todo list with a server that has
> been edited (worst case scenario for synchronising), the RFC hints
> that ETags are relevant but there are no implementation examples.
> - updating portions of a VTODO. It seems that a PUT of the entire
> VTODO is the only way... but that seems crazy, especially if there
> are attachments (or I don't support all the types within the item).
> On 19 Aug 2008, at 01:54, Randy Letness wrote:
>> Sam Halliday wrote:
>>> I've tried this request against my home collection (/dav/
>>> myusername/) on Chandler Hub with "Depth: 1" and it doesn't return
>>> anything. I've even tried it against one of my collections (/dav/
>>> mysername/mycollectionname) and still nothing, the response is
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <D:multistatus xmlns:D="DAV:"/>
>>> Any ideas? Is there something I'm missing in the request?
>> I've tried this REPORT (Depth 1) against a calendar collection and
>> it seems to work. The calendar-filter you are using only matches
>> VTODOs that do not have a COMPLETED property AND have a STATUS
>> property that is not equal to the text "CANCELLED". Since cosmo
>> does not use STATUS, this won't match notes created in cosmo. I
>> changed the filter by removing the second prop-filter that matches
>> STATUS and it correctly returns the VTODOS without COMPLETED.
>>> Also, the PROPFIND option you are referring to... do you have any
>>> example requests? This is not covered well in the RFC.
>> For example you can do something like:
>> curl -u user:pass -X PROPFIND -H "Depth: 1" -H "Content-Type: text/
>> xml" --data-ascii "<D:propfind xmlns:D=\"DAV:
>> \"><D:prop><D:resourcetype></D:resourcetype></D:prop></D:propfind>" http://localhost:8080/chandler/dav/username
>> and examine the results for each collection that has the C:calendar
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2443 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20080823/5ba7c528/smime.bin
More information about the cosmo-dev