[cosmo-dev] RFC4791 HTTP REPORT and Cosmo
Sam Halliday
sam.halliday at gmail.com
Sat Aug 23 11:57:12 PDT 2008
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 always
>>
>> ==============
>> <?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
> prop.
>
> -Randy
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
--
Sam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2443 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/cosmo-dev/attachments/20080823/cdc0643c/smime.bin
More information about the cosmo-dev
mailing list