Алгоритм синхронизации CALDAV

Question

Я пытаюсь реализовать syn с помощью отчетов caldav и sync, но у меня возникли концептуальные проблемы с синхронизацией одного календаря (одного VEVENT) между несколькими клиентами и сервером.

Большинство rfc ссылаются на использование etag, чтобы определить, изменился ли ресурс с момента последней синхронизации. (Если изменяется этаг, ресурс изменился с момента последней синхронизации). Это я получаю. Однако как узнать, какие изменения произошли недавно?

Например, клиент A имеет ical 'X', который был последний отредактирован в 1:00, и они синхронизируются с 8AM. Клиент B также имеет версию ical X, которую они редактировали на 2AM и синхронизировали в 7 утра. Таким образом, B более новый, чем A и B, синхронизированный до A.

Когда A синхронизируется, он увидит новую версию версии X. Из etag известно, что X изменился, но не «когда». Я предполагаю, что A должен переписываться с B, поскольку B является более новым (или, по крайней мере, может побуждать пользователя говорить, что B является более новым) .... это предположение верно/есть ли стандартный способ справиться с этой ситуацией?

Проблема в том, что при попытке выяснить, какой файл является более новым между сервером и клиентом. Этиг только может обнаружить «измененный», но не «новый». Последняя измененная дата, похоже, отражает дату загрузки iicals, а не последнюю дату редактирования на клиенте. Это заставляет меня поверить, что я чего-то не хватает. Есть ли общепринятый алгоритм синхронизации?

Answer 1

Последняя дата редактирования - всего лишь одна часть уравнения здесь. Более значимым является фактическое изменение. Возможно, вы отключили сигнал тревоги от устройства B (незначительное изменение), но изменили дату начала с устройства A (основное изменение). Таким образом, хорошо себя вести клиент должен приложить все усилия, пытаясь объединить эти два. Некоторые клиенты просто уведомят вас о том, что событие было отредактировано и спросит вас, какую копию сохранить, но без пользовательского интерфейса сравнения сбоку, это действительно запутывает для конечных пользователей. Без механизма слияния я бы просто проигнорировал etag и всегда перезаписывал.

Наконец, вы также должны беспокоиться о расписании мероприятия (см. http://tools.ietf.org/html/rfc6638#section-3.2.10).

Answer 2

Кроме того, файл iCal должен содержать номер SEQUENCE (увеличивается на каждое редактирование), что более важно, чем дата редактирования. Сравнивая SEQUENCE по крайней мере, вы можете решить, какое редактирование является более новым, если его значение не равно для обеих сторон.