Thanks for your investigation.
@McNetic said in Zimbra shared calendar: Some events are not synchronized:
In Response.kt lines 180 and following, the event URLs are compared to the calendar base url, which always contains the account user, so these events are rejected as HrefRelation.OTHER.
Well at least they’re classified as relation: other. dav4jvm doesn’t reject anything
They’re just not useful, because
REPORT calendar-query, but let’s simplify things and say we’re just using
PROPFIND, which would have to be able to enumerate all resources, too) work on collections (= directories) and request members of (= files in) this collection:
The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs.
Obviously, my previous caldav synchronisation software ignored this differences and I never had problems with that behaviour. If you are interested and would explain your intention on how to handle the situation, I might be able to provide a patch.
I wonder how they can do that, because I think it would break many things. I have seen servers which return nearly everything on
PROPFIND requests, including parent collections, completely unrelated resources, the root collection etc. I’d like to stick with the standards, and as far as I know and understand it, returning resources which are not the requested resource or members of this resource doesn’t make any sense and parsing these responses can cause various errors. In DAVx⁵, they’re just used for resource detection (then resources with
HrefRelation.OTHER are taken into consideration), [edit:] because properties like
current-user-principal can be used from any source and it improves the results.
If you have other conclusive interpretations of WebDAV/CalDAV (which would include how such non-member resources could be handled), please let me know. These things touch the deep core of DAVx⁵ (and my understanding of WebDAV/CalDAV), so I’ll be very cautious with changing those things. However, if there’s some mistake, it will of course have to be fixed.