CALDAV同步算法

Question

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

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

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

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

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

Answer 1

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

最后，您还应该担心活动的计划标记（请参阅http://tools.ietf.org/html/rfc6638#section-3.2.10）。

Answer 2

此外，iCal文件应包含SEQUENCE编号（每次编辑时递增），这对于编辑日期更为重要。通过比较SEQUENCE，至少你可以决定哪个编辑更新，如果它的值对于双方都不相等。