… 我认为作者使用iCalendar格式的方法是很好的，不过我发现各种日历软件对iCalendar功能的支持程度差异很大。为了避免处理这些麻烦，我某种程度上放弃了，决定将大部分元数据放入描述字段，而不是使用相应的属性。编辑：我的使用场景是编写了一段软件，用来从各种网站（Eventbrite、Meetup、酒吧问答公司、公共活动日历等）获取数据，筛选出我感兴趣的社交活动，然后将它们合并到一个日历中，我可以在我正常的日历软件中查看。
源讨论拥有自己的数据，第一部分：集成自托管的日历解决方案原帖 146 条评论 · 导入时统计把你的经验，加入这段讨论。
我认为CalDAV（以及它所基于的WebDAV协议）的核心问题在于，这几乎是所有W3C批准的标准所普遍存在的问题：它为了做太多事情而过度设计，而不是一个简洁的格式。 结果就是，这个协议本质上变成了各种不同想法的混乱集合，这不可避免地导致了很多服务根本不会尝试完全符合规范，因为这超出了它们实际想要实现的范围。 我不记得有没有见过一个W3C的数据格式规范没有变成这样，似乎总是这样发生。（这似乎不会发生在他们的低级协议规范中。）
完整原文我曾参与开发了所有苹果产品中的CalDAV客户端。 我同意，这个协议很糟糕。但我们也遇到了很多处理Exchange和Google的非符合规范的CalDAV服务器的问题，所有用户都把责任归咎于我们。 现在我在Google工作，我了解到gCal应用使用的是完全不同的协议。
完整原文> 最初，我选择将动态更新的iCal文件托管在S3存储桶中，并使用Android上的ICSx5与之同步。不需要CalDAV——只需要HTTPS。 但你也不能将这个集成到大多数日历中。我甚至不知道iCal文件是什么。我觉得我已经几十年没听说过“iCal”这个词了。 > 我知道我可能会因此遭到反对，但CalDAV真的很糟糕。 所有其他替代方案更糟糕。
完整原文书《Dreaming in Code》[1]详细讲述了CalDAV（和WebDAV）是如何通过Chandler日历程序（或试图构建它）的团队工作而产生的。我已经很久没读过这本书了（至少15年了），但我认为它部分讨论了这类协议在设计过程中如何在委员会中迷失方向。这个项目大约在2001年启动的事实也说明了日历问题已经存在了很长时间。所以，如果你想了解为什么它这么糟糕，我推荐你阅读这本书。 它也是关于初创公司和开源之间的冲突、产品开发以及软件开发整体的一个好故事。 [1] http://www.dreamingincode.com/ ; https://en.m.wikipedia.org/wiki/Dreaming_in_Code
完整原文我的CalDAV服务提供商是ZOHO。 为了与Android同步，我使用DAVX5，它运行一个后台同步服务（开源且无需root）。我花了很长时间才让它正常工作，可能是由于不同的CalDAV实现。DAVX5与ZOHO日历同步需要很长时间。 Ubuntu上的Evolution有很好的CalDAV支持，但每次在邮件视图和日历视图之间切换时，它都会刷新整个日历。刷新那个ZOHO日历需要很长时间，而ZOHO的速率限制非常严格，这导致我被软封禁了。 最新版的Thunderbird存在CalDAV不兼容的问题，它期望不同的HTTP成功代码。ZOHO返回的是200，但Thunderbird期望的是其他代码。（PS：Thunderbird的CalDAV代码是用JS编写的）。PS：这种情况只在第二个日历上发生。每当添加第二个日历后，就会开始失败。 所以，至少对于ZOHO来说，这确实是个麻烦事。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。