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

David Given dtrg at google.com
Wed Jun 6 18:00:25 PDT 2018


Thanks very much for this --- you'll have to bear with me as this it
involves more detailed knowledge of the protocol than I have handy, and
I'll have to check up with people.

One word of warning: the 'Import ICS' feature in our UI does *not* behave
the same way as the API --- it makes a copy of the event and adds it to the
user's calendar, which means the organiser gets changed. I don't think it's
relevant in this case but I'd strongly recommend testing with CalDAV
instead.

On Wed, 6 Jun 2018 at 23:52 Arnaud Quillaud <arnaudq at quillaud.org> wrote:

>
>
> On 01/06/2018 23:28, 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).
>
> There is a more fundamental reason to always use a CalDAV multi-get
> REPORT: caldav:calendar-data is not a WebDAV property and can be used
> *only* in the context of a CalDAV REPORT. From
> https://tools.ietf.org/html/rfc4791#section-9.6
>
> Note:  The CALDAV:calendar-data XML element is specified in requests
>       and responses inside the DAV:prop XML element as if it were a
>       WebDAV property.  However, the CALDAV:calendar-data XML element is
>       not a WebDAV property and, as such, is not returned in PROPFIND
>       responses, nor used in PROPPATCH requests.
>
>
> In practice of course, most servers will return "something" when
> calendar-data is asked for in a generic WebDAV REPORT or in a PROPFIND
> request. That "something" seems to be not so well defined in the case of
> Google.
>
> Arnaud Q
>
>
> 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
>
>
>
> _______________________________________________
> caldeveloper-l mailing listcaldeveloper-l at lists.calconnect.orghttp://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org
>
>
> _______________________________________________
> 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/20180607/c917242a/attachment.html>


More information about the caldeveloper-l mailing list