CALDAV同步算法

Question

我正在尝试使用caldav和同步报告实现syn，但是我在如何在多个客户端和服务器之间同步一个日历(一个VEVENT)方面遇到了概念上的问题。

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

例如，客户端A有一个上次在凌晨1点编辑的逻辑'X‘，它们在上午8点同步客户端B也有一个ical X版本，他们在凌晨2点编辑该版本，并在上午7点进行同步所以B比A新，A和B在A之前同步。

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

通常的问题是，当试图找出服务器和客户端之间的哪个文件较新时。etag只能检测“changed”，而不能检测“newer”。上次修改日期似乎反映了its上传日期，而不是其在客户端的最后编辑日期。这让我相信我错过了什么。有没有一些被普遍接受的同步算法？

Answer 1

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

最后，您还应该担心事件的计划标记(请参阅https://www.rfc-editor.org/rfc/rfc6638#section-3.2.10 )。

Answer 2

此外，iCal文件应包含序列号(在每次编辑时递增)，这比编辑日期更重要。通过比较序列，如果双方的值不相等，您至少可以确定哪个编辑是较新的。