Zusammenfassung

  • RFC 5267 erhält ein Such- oder Sortierergebnis als Ausgangsliste plus positionsabhängige ADDTO- und REMOVEFROM-Operationen, die in der empfangenen Reihenfolge und unter dem Tag des Ursprungskommandos angewandt werden.
  • Die Spezifikation bietet ausdrücklich keinen Schnappschuss. NOUPDATE kann die laufende Pflege ablehnen; CANCELUPDATE, Abwahl des Postfachs oder eine unerklärte Transportlücke beenden die Kontinuität.

Eine bewegte Liste kann längst die falsche Gegenwart zeigen

Bei einer Live-Suche gilt Bewegung schnell als Frischebeweis. Eine neue Nachricht erscheint, ein geändertes Flag entfernt einen Treffer, die Zählung reagiert. Doch jede dieser sichtbaren Reaktionen beweist nur, dass irgendeine Änderung angekommen ist. Sie beweist nicht, dass seit dem Anfang keine fehlte.

RFC 5267 erweitert SEARCH, UID SEARCH, SORT und UID SORT um UPDATE. Zunächst entsteht ein Ausgangsergebnis. Danach kann der Server unaufgeforderte ESEARCH-Antworten mit ADDTO und REMOVEFROM senden. Der Korrelator verweist auf das Tag des ursprünglichen Suchkommandos. Eine Änderung gehört deshalb zu genau dieser Abfrage, diesem Kennungsmodus und dieser Reihenfolge.

CONTEXT ist lediglich ein Hinweis auf wahrscheinliche Wiederverwendung. Der Server darf daraus einen Cache oder Index bilden oder den Hinweis ignorieren. Das beobachtbare Verhalten muss gleich bleiben. Folgerichtig stellt die RFC klar, dass keine snapshot facility existiert. Autorität entsteht nicht durch ein beim Server vermutetes Standbild, sondern durch ein nachweisbares Ausgangsergebnis und eine vollständige Folge gültiger Änderungen.

Positionsoperationen verlangen serielle Verarbeitung

ADDTO nennt Position und einzufügende Resultate; REMOVEFROM nennt Position und zu entfernende Resultate. SEARCH und SORT verwenden Nachrichtensequenznummern, die UID-Varianten UIDs. Da Positionen beteiligt sind, können dieselben Operationen in anderer Reihenfolge einen anderen Zustand erzeugen.

Der Client muss alle Elemente in der Reihenfolge ihres Auftretens verarbeiten, auch mehrere innerhalb einer ESEARCH-Antwort. Der Server muss sie so erzeugen, dass diese Verarbeitung die verlangte Sortierung erhält. Ein Ereignissystem, das Verbraucher parallel arbeiten lässt und später nach lokalen Zeitstempeln sortiert, kann damit eine protokollfremde Liste herstellen.

Der kleinste belastbare Beleg umfasst Suchprogramm, Kennungsmodus, gewünschte Ordnung, Tag, Ausgangsliste und monotone Empfangsfolge. Das Tag eines aktiven Kontexts darf nicht für einen weiteren verwendet werden; der Server muss eine Kollision mit BAD ablehnen. Das Tag ist der Zuordnungsschlüssel für unaufgeforderte Änderungen.

Auf der Leitung liegt die Bedeutung der Sequenznummer

Sequenznummern verändern sich durch EXPUNGE. Enthält ein durch Zustellung oder Append verursachtes ADDTO solche Nummern, muss es nach EXISTS kommen, weil sie erst dann gültig sind. Ein durch Expunge ausgelöstes REMOVEFROM muss vor EXPUNGE stehen, solange die alte Nummerierung noch interpretierbar ist.

EXISTS, FETCH, ESEARCH und EXPUNGE bilden daher ein gemeinsames Kausalprotokoll. Getrennte Warteschlangen, die später nach Dienstuhren zusammengefügt werden, erhalten diese Vorgabe nicht. ESEARCH darf ohne laufendes Kommando, während eines anderen Kommandos oder unter IDLE eintreffen. Wer nur Anfrage-Abschluss-Paare protokolliert, verpasst den unaufgeforderten Strom.

Sequenznummern im Suchprogramm selbst werden beim Empfang des Kommandos ausgewertet. Spätere Umnummerierung erzeugt nicht allein deswegen eine Nachricht. Den alten numerischen Ausdruck später neu zu deuten hieße, eine andere Suche auszuführen.

NOUPDATE trennt die erste Antwort vom laufenden Dienst

Der Server darf Aktualisierungen etwa wegen eines internen Kontextlimits verweigern. Dazu sendet er ein ungetaggtes NO mit NOUPDATE und dem betroffenen Suchtag. Andere Rückgabeoptionen bleiben wirksam.

So kann der Client brauchbare Zeilen und einen erfolgreichen Abschluss erhalten, ohne die verlangte Fortsetzung. Speichert er die Zeilen, verwirft aber NOUPDATE, erhält ein statisches Ergebnis den Status „live“. Das Betriebsmodell muss angefordert, angenommen, verweigert, aktiv, abgebrochen, durch Abwahl beendet und Kontinuität unbekannt unterscheiden.

Mindestens ein aktualisierbarer Kontext pro Client ist vorgeschrieben, mehr werden empfohlen. Sortierte Kontexte können teurer sein; ihre Ablehnung sagt daher nichts Sicheres über einen einfacheren Suchkontext. Ein Client darf günstiger neu versuchen oder sichtbar auf statisch zurückfallen. Verbergen darf er die Ablehnung nicht.

PARTIAL begrenzt die Ansicht, nicht den Änderungsstrom

PARTIAL liefert ein Positionsfenster und passt zu virtualisierten Listen. UPDATE wird jedoch von anderen Rückgabeoptionen nicht eingegrenzt. Mit PARTIAL können Änderungen außerhalb des sichtbaren Fensters eintreffen. COUNT, MIN und MAX beschränken den Strom ebenso wenig auf ihren Zusammenfassungswert.

Wer unsichtbare Deltas wegwirft, entzieht späteren Fensterpositionen die Grundlage. Das Produkt kann auf die Pflege des Gesamtkontexts verzichten; dann muss es ihn ungültig machen und neu basieren. Der Viewport ist eine Darstellung, keine Autoritätsgrenze.

Nach der Lücke heilt weiteres Fließen den Zustand nicht

Aktualisierungen enden, sobald das Postfach nicht mehr ausgewählt ist oder CANCELUPDATE die ursprünglichen Tags nennt. Wiederverbindung, neue Auswahl oder dieselbe Suchbedingung schaffen eine neue Beobachtung; sie setzen den alten Strom nicht fort.

Neben Verbindungsabbruch wirken Parserfehler, Backpressure-Verlust oder eine automatische Wiederverbindung mit altem UI-Zustand genauso. Sobald ein positionsbezogenes Delta fehlen kann, beweisen spätere Deltas keine Vollständigkeit. CONDSTORE und QRESYNC bieten eigene Resynchronisationswege mit eigenen Voraussetzungen. IDLE empfängt unaufgeforderte Antworten; NOTIFY beschreibt Ereignisinteressen. Keine dieser Fähigkeiten repariert durch bloße Existenz einen lückenhaften RFC-5267-Verlauf.

Running-Code Primacy richtet den Blick auf das tatsächlich laufende Objekt: exaktes Kommando, Fähigkeiten, Postfachauswahl, Basis, geordnete Patches und Ende. Ausgangsbeobachtung, UPDATE-Annahme, rekonstruierter Zustand, sichtbare Seite und Nutzerhandlung sind verschiedene Realitätsebenen. Lässt sich eine Zeile nicht zu Tag und Kausalfolge zurückverfolgen, besitzt die Organisation eine aktuelle Darstellung, aber keinen Nachweis der Gegenwart.

Quellen