Кратко

  • В RFC 8620 строка state представляет все данные одного типа в аккаунте; при её изменении клиент должен обновить кэш или запросить точные различия.
  • StateChange указывает на изменившиеся состояния аккаунтов и типов данных. Он не содержит сам по себе действующего субъекта, значений до и после, причины, доказуемого порядка или результата в почтовом ящике.

Сигнал, после которого нужен ещё один запрос

Neil Jenkins и Chris Newman в RFC 8620 решают задачу эффективной синхронизации. Мобильному клиенту не нужно постоянно получать весь набор данных, чтобы проверить устаревание своей копии. Ответ Foo/get возвращает короткую строку state. Если данные типа изменились, строка должна измениться; если нет, сервер обычно должен вернуть прежнее значение.

Это значение относится ко всем данным данного типа в аккаунте, а не только к объектам в одном ответе. Получив другую строку, клиент не должен угадывать её содержание: он отбрасывает кэш либо вызывает Foo/changes для получения точных изменений. Поэтому state — граница согласованности кэша, а не описание операционного события.

В строке не появляется автоматически аутентифицированный инициатор, запрос, решение авторизации, поля до и после, мотив, защищённая временная последовательность или наблюдение у получателя. Она подтверждает необходимость синхронизации. Для утверждения о конкретном изменении ящика требуются записи тех слоёв, где запрос был принят, политика применена, объект сохранён и результат наблюдался.

Список различий не равен полному аудиту

Метод /changes принимает sinceState, возвращает oldState, newState и может перечислить идентификаторы созданных, обновлённых и уничтоженных объектов. Это правильный инструмент для сведения локальной копии с сервером.

Но список идентификаторов не становится полным аудитом. Чтобы установить автора, нужны главный субъект, связанный запрос и решение об авторизации. Чтобы установить содержание, нужны релевантные представления до и после. Чтобы установить порядок и ответственность, нужны правила времени, целостности и хранения. Реализация может вести такие записи рядом с JMAP, но общий токен состояния их не обещает.

Один push может сжать несколько изменений

StateChange сопоставляет аккаунтам состояния типов данных, изменившихся после прошлого push. Клиент сравнивает их со своими значениями и при необходимости получает различия. Пример RFC допускает, что сервер объединяет несколько изменений из двух аккаунтов в один объект. Это полезно для сети, но исключает трактовку уведомления как журнала «одно событие — одна запись».

Вопрос Полезное доказательство JMAP Что требуется дополнительно
Актуален ли кэш? Совпадающий state Ничего для этого узкого вопроса
Что нужно синхронизировать? Идентификаторы из /changes Содержимое объектов при необходимости
Кто изменил ящик? StateChange один этого не доказывает Субъект, запрос и авторизация
Каков итог для получателя? Общий state этого не доказывает Наблюдение на границе доставки, ящика или чтения

Сила архитектуры, связанной с Jenkins, именно в её ограниченности: она обнаруживает расхождение и даёт путь к сходимости. Для синхронизации и для аудита должны сохраняться разные доказательства.

Источники