CalDAV: Sync colors after setup



  • another solution would be: sync color max. once of 10 times (smaller overheader, but still syncing)…?


  • developer

    @stefan-niedermann Don’t like non-deterministic algorhithms. The overhead wouldn’t be that much, so meta-data (but then also including calendar title, etc) should be synced either always or on manual sync else. However, as said before, this new feature has low priority.

    By the way, do you know a documentation/standard where the Apple calendar-color property in the http://apple.com/ns/ical/ namespace is documented? I had to implement it from hearsay…



  • I too have hit this problem (change in color does not get sync’d). The other open source client that I try for comparison is https://github.com/gggard/AndroidCaldavSyncAdapater/ and that syncs the color changes.

    I too implemented this from somebody’s traffic capture as a local patch to Radicale so I get the colors now. 🙂



  • I also have this issue against Kolab, including with the first time I hook things up.

    Works fine for same accounts with other CalDAV plugins.


  • developer

    I also have this issue against Kolab, including with the first time I hook things up.

    Can you please provide logs? It’s no fun to guess around what the cause might be without having an informative basis.

    By the way, does anyone know a documentation/standard where the Apple calendar-color property in the http://apple.com/ns/ical/ namespace is documented? I had to implement it from hearsay…



  • Alright. So essentially I should remove the accounts again, turn on debugging and then hook it up once more?

    Anything in particular I should look for in the logs?


  • developer

    Alright. So essentially I should remove the accounts again, turn on debugging and then hook it up once more?

    Yes please, that would be very helpful.

    Anything in particular I should look for in the logs?

    There should be a PROPFIND request on your calendar-home-set. In the reply, there should be a color element. Further debugging will depend on whether it’s there and how it’s formatted.



  • I checked this and the response includes this:

    <x5:calendar-color xmlns:x5="http://apple.com/ns/ical/">DC143C</x5:calendar-color>
    

    I suppose the problem is that the color is not given as #DC143C. This is already fixed in Kolab.org upstream, but not rolled out to MyKolab.com. @rfc2822 can you confirm that DAVdroid chokes on the color value?


  • developer

    I suppose the problem is that the color is not given as #DC143C. This is already fixed in Kolab.org upstream, but not rolled out to MyKolab.com. @rfc2822 can you confirm that DAVdroid chokes on the color value?

    Yes, DAVdroid currently expects this pattern. I wonder whether it should be changed to allow color names without leading #. It’s really annoying to implement things by feeling and hearsay – I think there just is no standard for the calendar-color element, although it has an xmlns.



  • We could also not find specification for this. Here’s our ticket about the issue for reference. So since we changed to the leading #, you might as well stay with it. However, if you want DAVdroid to be more robust, you might as well make the # optional.


  • developer

    DAVdroid fetches the CTag for the collection on every sync – the same request could be used to fetch color, title and description again, too.



  • Given that we seem to know what is going on ("#" vs no “#”) it seems that debugging is no longer required. So if possible I’d avoid having to go through the cycle.



  • I think this can be closed.


  • developer

    Thanks for the hint, closing



  • I’m starting to use DAVDroid and wanted to know: How is the current behavior regarding color sync? Does it still download the colors at setup time?


  • developer

    Does it still download the colors at setup time?

    Yes: At the moment, colors are only fetched here from the PROPFIND response, then put into ServerInfo.ResourceInfo and then later used when creating the LocalCollections.



  • I suppose a manually triggered re-discovery of all collections would fix this issue (as well as add the ability to sync new collections). See CalDAV-Sync for what I mean.


  • developer

    I suppose a manually triggered re-discovery of all collections would fix this issue (as well as add the ability to sync new collections).

    Please follow up in in #219 and #243 for that.

    See CalDAV-Sync for what I mean.

    As far as I know, CalDAV-Sync is not open-source? So unfortunately, I can’t see how it’s handled there.



  • As far as I know, CalDAV-Sync is not open-source? So unfortunately, I can’t see how it’s handled there.

    I meant how it is implemented UI-wise: Part of collection discovery, which doesn’t happen regularly but has to be triggered manually.


  • developer

    I meant how it is implemented UI-wise: Part of collection discovery, which doesn’t happen regularly but has to be triggered manually.

    Ah ok, this is #219. Please follow up there.

    I don’t know when this will be done, at the moment I’m happy about tasks sync 🙂


Log in to reply