CALDAV 同步算法答案

【问题标题】：CALDAV sync algorithmCALDAV 同步算法
【发布时间】：2013-11-27 23:52:35
【问题描述】：

我正在尝试使用 caldav 和同步报告来实现同步，但是我遇到了关于如何在多个客户端和服务器之间同步一个日历（一个 VEVENT）的概念性问题。

大多数 rfc 指的是使用 etag 来确定资源自上次同步后是否发生了变化。（如果 etag 更改，则资源自上次同步后已更改）。我明白了。但是我怎么知道哪个更改是最近的？

例如，客户端 A 有一个在凌晨 1 点最后编辑的 ical“X”，它们在早上 8 点同步。客户端 B 也有一个 ical X 版本，他们在凌晨 2 点编辑并在早上 7 点同步。所以 B 比 A 更新，B 在 A 之前同步。

当 A 同步时，它会看到 B 的新版本 X。从 etag 中它知道 X 已更改，但不是“何时”更改。我假设 A 应该用 B 覆盖，因为 B 较新（或者至少能够提示用户说 B 较新）....这个假设是否正确/是否有处理这种情况的标准方法？

一般的问题是当试图找出服务器和客户端之间的哪个文件更新时。 etag 只能检测“更改”但不能检测“更新”。最后修改日期似乎反映了 icals 上传日期，而不是它在客户端上的最后编辑日期。这让我相信我错过了一些东西。是否有一些普遍接受的同步算法？

【问题讨论】：

标签： caldav

【解决方案1】：

最后一次编辑日期只是其中的一部分。更有意义的是实际的修改。您可能关闭了设备 B 的警报（微不足道的更改），但更改了设备 A 的开始日期（重大更改）。因此，行为良好的客户应该尽最大努力尝试将两者合并。一些客户只会通知您该事件已被编辑，并会询问您要保留哪个副本，但没有并排比较 UI，这对最终用户来说确实令人困惑。如果没有合并机制，我只会忽略 etag 并始终覆盖。

最后，您还应该担心活动的日程安排标签（请参阅https://www.rfc-editor.org/rfc/rfc6638#section-3.2.10）。

【讨论】：

【解决方案2】：

iCal 文件还应包含 SEQUENCE 编号（在每次编辑时递增），这比编辑日期更重要。通过比较 SEQUENCE 至少您可以确定如果双方的值不相等，则哪个编辑较新。

【讨论】：