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

[David Given]

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> 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
> 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
>
> _______________________________________________
> caldeveloper-l mailing list
> 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/2a134be2/attachment-0001.html>