Основная проблема заключается в следующем: после разделения не существует документированного способа связать получившиеся мастер-файлы (M1). → M2) как единая логическая серия.
Официальная документация описывает создание повторений и переопределения экземпляров, но не описывает, как представляются или связываются разделения, запускаемые пользовательским интерфейсом. Это заставляет клиентов синхронизации полагаться на эмпирическое поведение.
Я провел контролируемые тесты и проанализировал данные производственной синхронизации (около 1200 основных событий). Поведение единообразно, но недокументировано.
Наблюдаемое поведение
Когда пользователь выбирает "Это и последующие события" на главном M1:
- M1 исправляется с добавлением UNTIL RRULE.
- Новый главный M2 появляется со своим собственным RRULE (без UNTIL или новым COUNT).
- Поведение M2.id разделяется на два шаблона:
- ~50%: _R
- ~50 %: совершенно новый, несвязанный идентификатор
Мы не определили, что определяет, какой формат используется.
- При каскадном разбиении префикс _R (когда присутствует) всегда использует исходный корневой идентификатор, а не непосредственный родительский элемент. Вложенности не происходит.
- Переопределения после обрезки:
- Сохраните исходный идентификатор
- Имейте recurringEventId и iCalUID, переписанные автоматически, чтобы они указывали на M2
- обновляются на месте, а не удаляются/создаются заново
- Переопределения до завершения не изменяются, но могут снова появиться в следующей синхронизации без фактических изменений.
- :
Код: Выделить всё
iCalUID- Одинаково для главного устройства и его переопределений (соответствует RFC 5545)
- Разница между M1 и M2 после разделения
- M1 и M2 отображаются вместе в одном и том же event.list?syncToken=... diff.
- Удаление M1 с помощью «Удалить все» также отменяет M2 и все переопределения, несмотря на отсутствие общедоступной связи.
- Если M1 усекается до нуля, он отменяется, и M2 переносит серию вперед.
- Что определяет формат M2.id?
Когда он использует _R, а не совершенно новый идентификатор? - Является ли шаблон _R документированный контракт?
Можем ли мы полагаться на:- Наличие шаблона
- Использование корневого идентификатора (никогда не вложенного)
Или это чисто деталь реализации?
- Поддерживаются ли какие-либо способ связать М1 и М2?
При этом:- имеет значение null на M2
Код: Выделить всё
recurringEventId - отличается
Код: Выделить всё
iCalUID - Задокументированных полей обратных ссылок не существует
- Шаблон идентификатора работает только примерно в 50 % случаев
- Стабильно ли поведение переопределения переназначения?
В частности: сохранение id при переписывании recurringEventId и iCalUID на месте. - Как API внутренне идентифицирует «логическую серию»?
Каскад «Удалить все» подразумевает внутреннюю связь. Есть ли у клиентов какой-либо способ надежно получить доступ к нему или сделать вывод?
Без надежного и документированного способа связать M1 ↔ M2 клиенты синхронизации не могут правильно реализовать такие операции, как «редактировать все» между разбиениями.
Пользователи воспринимают единую логическую серию, но API предоставляет несколько несвязанных главных узлов и только частичные эвристики (например, префикс идентификатора), которые являются противоречивыми.
Если ответ заключается в том, что публичных связей не существует и шаблоны идентификаторов не являются договорными, это также полезно — это означает, что клиенты должны вернуться к эвристике или согласованию, управляемому пользователем.
Любые указатели на документацию, подтвержденное поведение, или рекомендуемые шаблоны будем очень признательны.
Спасибо!
