[caldeveloper-l] REPORT <sync-collection> for <caldav:calendar-data> --- Google returning only updated event instances
Andri Möll
andri at dot.ee
Wed Jun 6 03:28:58 PDT 2018
> We've had a few reports of something not being right with CalDAV
> syncing, but nobody's ever come up with a reproducable test case. So
> if you have a concrete example of unexpected results, then yes, we're
> very interested.
I'm happy to hear. What I described initially is fully reproducible.
It's pretty much as I hinted:
1. Import recurring event without master to Google Calendar. E.g.
> BEGIN:VCALENDAR
> VERSION:2.0
> BEGIN:VEVENT
> UID:44b06ab7-cc52-428d-a28b-438eb19cae1d
> RECURRENCE-ID:20180618T133742Z
> SUMMARY:RECURRENCE-ID without repeatee, part 1
> DTSTART:20180618T133742Z
> DURATION:PT6H
> END:VEVENT
> END:VCALENDAR
2. Get sync-token.
3. Add another recurring event instance without master (same UID).
> BEGIN:VCALENDAR
> VERSION:2.0
> BEGIN:VEVENT
> UID:44b06ab7-cc52-428d-a28b-438eb19cae1d
> RECURRENCE-ID:20180625T133742Z
> SUMMARY:RECURRENCE-ID without repeatee, part 2
> DTSTART:20180625T133742Z
> DURATION:PT6H
> END:VEVENT
> END:VCALENDAR
4. Use sync-token and get back <calendar-data> containing only the last
instance, not the first
> I'd intuitively expect, though ('intuitively' meaning 'I haven't
> actually checked in the RFC') that both sync-collection with a token
> /would/ only report the changed event instances --- it shouldn't be
> repeating data the client already knows. Is this incorrect?
My spec reading says it's incorrect as I haven't seen any mention of how
those changes should be reported. As I alluded to before, Google
CalDAV's behavior when deleting _only one_ of those event instances
doesn't make much sense either --- you get an empty VCALENDAR. Same when
deleting both instances together (see my email below).
On 06/06/2018 01:42 AM, David Given wrote:
> I am currently in my hotel in Tokyo waiting to go off to CalConnect
> myself, so...
>
> We've had a few reports of something not being right with CalDAV
> syncing, but nobody's ever come up with a reproducable test case. So
> if you have a concrete example of unexpected results, then yes, we're
> very interested.
>
> I'd intuitively expect, though ('intuitively' meaning 'I haven't
> actually checked in the RFC') that both sync-collection with a token
> /would/ only report the changed event instances --- it shouldn't be
> repeating data the client already knows. Is this incorrect?
>
> (The Oauth Playground at
> https://developers.google.com/oauthplayground/ is useful for sending
> raw CalDAV requests to the Google servers, BTW, although it only
> supports GET/POST/PUT/DELETE/PATCH.)
>
> On Sat, 2 Jun 2018, 07:08 Bron Gondwana, <brong at fastmailteam.com
> <mailto:brong at fastmailteam.com>> wrote:
>
> 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
>>>> <mailto: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 <mailto:brong at fastmailteam.com>
>>>
>
> --
> Bron Gondwana, CEO, FastMail Pty Ltd
> brong at fastmailteam.com <mailto:brong at fastmailteam.com>
>
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> <mailto:caldeveloper-l at lists.calconnect.org>
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20180606/8ca908ea/attachment-0001.html>
More information about the caldeveloper-l
mailing list