Zusammenfassung

  • RFC 8620 beschreibt state als Zustand aller Daten eines Typs in einem Konto. Bei einer Abweichung muss ein Client seinen Cache verwerfen oder die genauen Differenzen abrufen.
  • Ein StateChange benennt veränderte Konto-/Datentyp-Zustände. Er trägt nicht allein Akteur, Vorher-/Nachher-Werte, Ursache, belastbare Reihenfolge oder ein Mailbox-Ergebnis.

Eine Meldung für den nächsten Abruf

Neil Jenkins und Chris Newman entwerfen in RFC 8620 einen Weg, auf dem ein mobiler Client nicht fortwährend ganze Datensätze laden muss. Foo/get liefert eine kurze state-Zeichenfolge. Ändern sich die Daten, muss sich diese Zeichenfolge ändern; bei unveränderten Daten sollte der Server denselben Wert zurückgeben.

Der Wert ist weder nur auf die in einer Antwort sichtbaren Objekte beschränkt noch eine Ereigniserzählung. Er steht für alle Daten dieses Typs im Konto. Bei einem abweichenden Wert soll der Client seinen Cache verwerfen oder Foo/changes aufrufen, um die genauen Änderungen abzurufen. Der Zustand markiert damit eine Cache-Grenze.

Aus dieser Grenze folgen keine Fakten über einen authentifizierten Auftraggeber, einen genehmigenden Policy-Entscheid, die vorherigen und nachfolgenden Felder, ein Motiv oder eine dauerhaft beweisbare Zeitfolge. Ein anderer Zustand kann die Aussage stützen, dass Abgleich nötig ist. Für eine Aussage über eine konkrete Mailbox-Änderung müssen die Belege von den Stellen kommen, die Anfrage, Berechtigung, Objekt und Beobachtung tatsächlich führen.

Änderungen abrufen ist nicht vollständig auditieren

/changes nimmt sinceState entgegen und gibt oldState, newState sowie gegebenenfalls Kennungen erstellter, geänderter und gelöschter Objekte zurück. Das genügt, um den Client-Cache zu konvergieren.

Eine Kennungsliste ist dennoch kein vollständiges Audit. Wer gehandelt hat, verlangt Principal, korrelierte Anfrage und Autorisierungsentscheidung. Was geändert wurde, verlangt relevante Vorher-/Nachher-Repräsentationen. Eine belastbare Chronologie verlangt Zeitsemantik, Integrität und Aufbewahrung. Ein Dienst kann diese Belege neben JMAP vorhalten; ein generischer Zustandswert behauptet sie nicht.

Ein Push kann mehrere Veränderungen zusammenfassen

StateChange ordnet Konten die Zustände der Datentypen zu, die sich seit dem letzten Push verändert haben. Der Client vergleicht und holt bei Bedarf Differenzen. Das RFC-Beispiel erlaubt dem Server, mehrere Änderungen aus zwei Konten in ein Objekt zusammenzufassen. Das spart Verkehr, macht die Meldung aber gerade nicht zu einem Eins-zu-eins-Ereignisprotokoll.

Frage Nützlicher JMAP-Beleg Zusätzlich nötig
Ist der Cache aktuell? Übereinstimmender state Nichts für diese enge Frage
Was ist abzugleichen? Kennungen aus /changes Bei Bedarf Objektinhalt
Wer änderte eine Mailbox? Nicht durch StateChange allein Principal, Anfrage, Autorisierung
Welches Ergebnis hatte ein Empfänger? Nicht durch generischen Zustand Beobachtung an Zustell-, Mailbox- oder Leseboundary

Die Stärke der mit Jenkins verbundenen Architektur liegt in dieser Bescheidenheit: Sie zeigt eine Divergenz und liefert einen Weg zur Konvergenz. Synchronisationsbelege und Auditbelege müssen jedoch getrennt bleiben.

Quellen