[cosmo-dev] RFC4791 HTTP REPORT and Cosmo

[Sam Halliday]

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

-- 
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/5ba7c528/smime.bin