CALDAV同步算法

Question

我試圖使用caldav和同步報告來實現syn，但是我有關於如何在多個客戶端和服務器之間同步一個日曆（一個VEVENT）的概念性問題。

大多數的RFC參考使用的eTag，以確定是否一個資源已經改變了自上次同步。 （如果etag發生變化，則自上次同步以來資源已更改）。我明白了。但是，我怎麼知道哪個更新更近？

例如客戶機A具有將iCal「X」，這是最後在上午01點編輯和它們在同步8AM。客戶端B還有一個Xical版本，他們在2AM編輯並在7AM同步。所以B是新的，然後A和B A.

當A同步會看到B的新X的版本從它知道，X已經改變的eTag而不是「何時」前同步。我假設A應該用B覆蓋，因爲B更新（或者至少能夠提示用戶說B更新）....這個假設是否正確/是否有標準的方法來處理這種情況？

的問題一般是試圖找出哪些文件是在服務器和客戶端之間更新時。 etag只能檢測'已更改'，而不能'更新'。上次修改日期似乎反映了客戶上傳日期，而不是客戶上次修改日期。這讓我相信我錯過了一些東西。有一些普遍接受的同步算法嗎？

Answer 1

最後的編輯日期只是這裏的一個方程式。實際修改更有意義。您可能已關閉設備B的警報（無意義的更改），但更改了設備A的開始日期（主要更改）。因此，一個表現良好的客戶應盡最大努力試圖合併這兩者。 某些客戶只會通知您事件已被編輯，並會詢問您要保留哪個副本，但沒有並排比較用戶界面，這對最終用戶來說確實很混亂。 沒有合併機制，我會忽略etag並始終覆蓋。

最後，你也應該擔心的事件（見http://tools.ietf.org/html/rfc6638#section-3.2.10）的日程表標籤。

Answer 2

另外的iCal文件應包含序列號（遞增每個編輯），這是更重要的是，編輯的日期。通過比較SEQUENCE，至少你可以決定哪個編輯更新，如果它的值對於雙方來說都不相等。