CALDAV 동기화 알고리즘

Question

나는 caldav 및 동기화 보고서를 사용하여 syn을 구현하려고하지만 여러 클라이언트와 서버간에 하나의 달력 (하나의 VEVENT)을 동기화하는 방법에 대한 개념적인 문제가 있습니다.

대부분의 rfc는 마지막으로 동기화 된 이후 자원이 변경되었는지 여부를 결정하기 위해 etag를 사용하는 것을 말합니다. etag가 변경되면 마지막 동기화 이후 자원이 변경된 것입니다. 나는 그것을 얻는다. 그러나 최근 변경 사항을 어떻게 알 수 있습니까?

예를 들어 클라이언트 A는 마지막으로 오전 1시에 편집되고 오전 8시에 동기화되는 그래픽 'X'가 있습니다. 클라이언트 B는 또한 ical X 버전을 가지고 있으며, 2AM에서 편집하고 7AM에서 동기화합니다. 따라서 B가 새로운 것이고 A와 B가 A보다 먼저 동기화됩니다.

A가 동기화되면 B의 새 X 버전이 표시됩니다. etag에서 X는 변경되었지만 '변경'은 아님을 알 수 있습니다. 나는 A가 B로 덮어 써야한다고 가정하고 있는데, B가 더 새로운 것 (또는 적어도 B가 더 새로운 것을 말하는 사용자를 프롬프트 할 수 있기 때문이다.) ....이 가정은 정확하다 /이 상황을 처리하는 표준 방법이 있는가?

일반적으로 서버와 클라이언트간에 어떤 파일이 더 새로운 것인지 파악하려고 할 때 문제가 발생합니다. etag은 '변경됨'만 감지 할 수 있지만 '최신'은 감지 할 수 없습니다. 마지막으로 수정 한 날짜는 클라이언트의 최종 편집 날짜가 아니라 ical 업로드 날짜를 반영한 ​​것 같습니다. 이것은 제가 뭔가를 놓치고 있다고 믿게합니다. 동기화를 위해 일반적으로 받아 들여지는 알고리즘이 있습니까?

Answer 1

마지막 편집 날짜는 방정식의 한 부분 일뿐입니다. 더 의미있는 것은 실제 수정입니다. 장치 B에서 경보를 끄고 (사소한 변경) 장치 A (주요 변경)에서 시작 날짜를 변경했을 수 있습니다. 따라서, 잘 행동하는 클라이언트는이 둘을 병합하려고 최선을 다해야합니다. 일부 클라이언트는 이벤트가 편집되었음을 알리고 유지할 복사본을 물을 것입니다.하지만 사이드 바이 바이 비교 UI가 없으면 최종 사용자에게는 이것이 혼란 스럽습니다. 병합 메커니즘이 없으면 나는 단지 etag을 무시하고 항상 덮어 씁니다.

마지막으로 일정의 일정 태그에 대해서도 걱정해야합니다 (http://tools.ietf.org/html/rfc6638#section-3.2.10 참조).

Answer 2

또한 iCal 파일에는 편집 날짜가 더 중요한 SEQUENCE 번호 (각 편집시 증가)가 있어야합니다. 최소한 SEQUENCE를 비교하여 값이 양 당사자에 대해 동일하지 않으면 어떤 편집이 더 최근인지를 결정할 수 있습니다.