要約

  • RFC 8620 の state は、アカウント内のあるデータ型全体の状態を表す。値が変われば、クライアントはキャッシュを捨てるか正確な差分を取得する。
  • StateChange は変化したアカウントと型を知らせる同期信号であり、行為者、オブジェクトの前後値、理由、証拠としての順序、メールボックスの結果を単独では持たない。

次の問い合わせを求める短い信号

Neil Jenkins と Chris Newman の RFC 8620 は、モバイルやウェブのクライアントが毎回すべてのデータを取り直さずに済むようにする。Foo/get は短い state 文字列を返す。対象型のデータが変われば文字列は変わらなければならず、変わらなければサーバーは通常同じ値を返す。

この値は特定の応答に含まれたオブジェクトだけでなく、そのアカウントの当該型全体を指す。異なる値を受けたクライアントは、文字列から内容を推測しない。RFC 8620 は、キャッシュを破棄するか Foo/changes を呼んで正確な変更を取るよう求める。つまりこれはキャッシュの整合性境界であり、出来事の説明文ではない。

新しい状態値には、要求を出した主体、許可を与えたポリシー、変更前後の値、理由、保存された時系列は自動的には入らない。同期が必要かどうかには答えるが、責任を伴うメールボックス変更の問いには別の証拠が必要である。

差分取得と監査は別の仕事

/changes ではクライアントが sinceState を渡し、サーバーは oldState、newState、作成・更新・削除された識別子を返せる。これはローカルの見え方を追いつかせるための手順である。

識別子の列挙も完全な監査にはならない。誰が変更したかには認証済み主体、相関する要求、認可決定が要る。何が変わったかには必要な前後表現が要る。順序と追跡可能性には時刻の意味、完全性保護、保持方針が要る。JMAP 実装はそれらを別に作れるが、汎用状態文字列が供給したと呼ぶことはできない。

一つの push に複数の変化

StateChange は、前回の push 以後に変わったデータ型の状態をアカウントごとに対応付ける。クライアントは自分の値と比べ、必要なら差分を取得する。RFC の例では、サーバーは二つのアカウントにまたがる複数の変更を一つのオブジェクトへまとめられる。

この集約は同期には利点だが、監査の読み方には限界を作る。一つの通知は一つの操作、一人の利用者、一通のメール、一つの順序表を意味しない。

問い 有用な JMAP 証拠 追加で必要な証拠
キャッシュは最新か 一致する state この限定した問いには不要
何を再取得すべきか /changes の識別子 必要ならオブジェクト内容
誰がメールボックスを変えたか StateChange 単独では不十分 主体、要求、認可
利用者側で何が起きたか 汎用 state では不十分 配送・保存・閲覧境界の観測

Jenkins の設計は、同期の合図を過大な保証に変えない点で強い。同期には同期の記録を、監査には監査の記録を残すべきである。

出典