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

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

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

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

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

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


person user1499506    schedule 03.07.2012    source источник


Ответы (2)


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

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

person Arnaud Quillaud    schedule 15.02.2013

Также файл iCal должен содержать номер ПОСЛЕДОВАТЕЛЬНОСТИ (увеличивающийся при каждом редактировании), который более важен, чем дата редактирования. По крайней мере, сравнивая ПОСЛЕДОВАТЕЛЬНОСТЬ, вы можете решить, какое редактирование новее, если его значение не равно для обеих сторон.

person Andrew    schedule 27.11.2013