[caldeveloper-l] REPORT <sync-collection> for <caldav:calendar-data> --- Google returning only updated event instances

Bron Gondwana brong at fastmailteam.com
Fri Jun 1 15:08:56 PDT 2018


Maybe Robert can check with somebody from Google next week at CalConnect
in Tokyo :)
With Cyrus the delete will return whatever the standard delete is, then
404 for the get.
Bron.


On Sat, Jun 2, 2018, at 07:59, Andri Möll wrote:
> That works indeed and I'll switch over to sync-collection + multiget
> as well, but [Google's] <calendar-data>'s behavior in response to
> <sync-collection> is quite a nut in its own right. Delete the last
> instance you have of a repeating event without a master and Google
> gets you a "200 OK" with an empty VCALENDAR. Go GET or multiget it
> and you get 404.> I haven't checked other servers. Happen to know how Cyrus behaves?


> 


>


>> Surely <caldav:calendar-data> isn't defined differently in the REPORT
>> context and in the PROPFIND context?> 


> Correction to my own question --- "defined differently in <sync-
> collection> vs <calendar-multiget>". Noticed in RFC 4791 that <calendar-
> data> isn't supposed to be returned in PROPFIND.> 
> On 06/01/2018 09:28 PM, Bron Gondwana wrote:
>> What happens if you just fetch the href in changes and then use a get
>> or multiget to fetch the calendar data?>> 
>> I'm pretty sure I changed all our perl client code to do that a while
>> back for unrelated reasons (ok, because some servers just error out
>> if you try to fetch too many items at once, so we batch the calendar
>> data requests).>> 
>> Bron.
>> 
>> 
>> On Sat, Jun 2, 2018, at 02:58, Andri Möll wrote:
>>> Hey,


>>> Does anyone know what's up with Google Calendar's CalDAV REPORT <sync-
>>> collection> with <sync-token> response only returning updated
>>> recurring event instances in <caldav:calendar-data> and not the
>>> entire iCalendar with its master and other [unchanged] instances?
>>> Surely <caldav:calendar-data> isn't defined differently in the
>>> REPORT context and in the PROPFIND context?>>> Throwing in <caldav:comp> in hopes that it'll trigger a full
>>> response doesn't seem to work either.>>> 


>>>> <caldav:calendar-data>
>>>>   <caldav:comp name="VCALENDAR">
>>>>     <caldav:allprop/>
>>>>     <caldav:allcomp/>
>>>>   </caldav:comp>
>>>> </caldav:calendar-data>
>>> 
>>> 


>>> Thanks!


>>> Andri


>>> _________________________________________________
>>> caldeveloper-l mailing list
>>> caldeveloper-l at lists.calconnect.org
>>> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org>> 
>> --
>>   Bron Gondwana, CEO, FastMail Pty Ltd
>>   brong at fastmailteam.com
>> 

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong at fastmailteam.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20180602/98dce591/attachment-0001.html>


More information about the caldeveloper-l mailing list