I think the author's approach for using iCalendar format is a good one, though what I've discovered …

I think the core issue with CalDAV (and by extension, the protocol it's build on top of, WebDAV) is one somewhat endemic with most W3 approved standards: it's way too overengineered to do too many things at the same time rather than a lean format. The result is a protocol that's essentially become a furball of different ideas mashed together, which inevitably leads to the situation where a lot of services just... don't try to be full spec compliant since it's out of scope for what they actually want to do. I don't think I've ever seen a W3 data format spec that didn't end up this way, it just always seems to happen. (It doesn't seem to happen with their lower level protocol specifications.)

I worked on the CalDAV client that’s in every Apple product. I agree, the protocol sucks. But we also had a ton of trouble handling Exchange and Google’s non-compliant CalDAV server, which all the users blamed us for. Now that I work at Google I can see that gCal apps use an entirely different protocol.

> Instead, initially went with the approach of hosting my dynamically updating iCal file in an S3 bucket and using ICSx5 on Android to sync with it. No CalDAV needed – just HTTPS. Well you also can't integrate this into most calendars. I don't even know what the hell an iCal file is. I haven't even heard "iCal" in what feels like decades. > I know I will probably get pushback over this, but CalDAV sucks. All the alternatives are worse.

The book Dreaming in Code [1] goes into great detail about how CalDAV (and WebDAV) came about through the work of the group who built the Chandler calendar program (or tried to). It’s been a while since I read it (at least 15 years), but I think it partially discusses some of the ways a protocol like this can get lost in committees during the design process. The fact that this project started around 2001 should also be informative about how long calendaring has been a problem. So, if you’d like to know about why it sucks, I’d recommend it. It’s also a good story about the conflict between startups and open source, building products, and software development in general. [1] http://www.dreamingincode.com/ ; https://en.m.wikipedia.org/wiki/Dreaming_in_Code

My CalDAV provider is ZOHO. To sync with Android I use DAVX5 which runs a background sync service (open source and non-root). I had a lot of issues getting it working, could be because of different CalDAV implementations. DAVX5 to ZOHO calendar sync takes forever. Evolution on Ubuntu has pretty good CalDAV support, but it would refresh the entire calendar each time upon switchin between the mail view and calendar view. Refreshing that ZOHO calendar takes forever and ZOHO has pretty frugal rate limits, so it ends up soft-banning me. Latest Thunderbird has a CaldDAV incompatibility where it expects a different HTTP success code. ZOHO gives a 200, but Thunderbird expects something else. (PS Thunderbird CalDAV code is written in JS). PS This only happens on the second calendar. Whenever you add a second one, it starts failing. So it is quite a pain, at least with ZOHO.