Zusammenfassung

  • PubSubHubbub ersetzte das ständige Nachfragen jedes Feed-Lesers durch eine Kette aus Herausgeber, Hub und Rückrufadresse. Der Entwurf von 2010 ließ den Hub Änderungen abrufen und an Abonnenten verteilen. Die Geschwindigkeit erhielt eine Zwischenstelle.
  • Die WebSub-Empfehlung von 2018 machte deren Bedingungen sichtbar: 202 Accepted bestätigte zunächst nur den Eingang eines Antrags. Rückrufadresse und Absicht mussten geprüft werden; Abonnements liefen ab und mussten vom Abonnenten rechtzeitig erneuert werden.

Die Leser hörten auf, überall anzuklopfen

Ein Feed-Reader konnte die gleiche Datei bei jeder Website immer wieder anfordern. Häufig hatte sich nichts geändert. Der Entwurf PubSubHubbub Core 0.3 vom Februar 2010 schlug eine andere Arbeitsteilung vor. Der Herausgeber nannte in seinem Atom- oder RSS-Feed einen Hub und meldete ihm Änderungen. Der Hub rief den Feed ab und schickte neue Inhalte an die Rückrufadressen der Abonnenten.

Der Herausgeber musste damit weniger identische Anfragen beantworten. Die Verteilung lag bei einem Knoten. Die Referenzimplementierung des Entwurfs zielte auf Google App Engine, doch der Text betonte, dass jeder einen Hub betreiben konnte. Das Protokoll brauchte kein Firmenmonopol. Ein bestimmtes Abonnement durchlief trotzdem den Hub, den der Herausgeber für seinen Feed ausgewiesen hatte.

Ein Abonnent gab eine aus dem Netz erreichbare Rückrufadresse an. Der Hub schickte dorthin eine hub.challenge, die unverändert zurückkommen musste. So konnte kein Dritter eine fremde Adresse nach Belieben an- oder abmelden. Der Hub verwaltete zugleich die Liste und den Versand. Das wiederholte Klopfen verschwand nicht als Arbeit, sondern wurde zur Aufgabe einer Verteilstelle.

Der 202-Beleg war noch kein Abonnement

Im Januar 2018 veröffentlichte das W3C WebSub als Empfehlung, den neuen Namen von PubSubHubbub. Die Fassung von 2018 behielt Herausgeber, Hub und Abonnent bei und beschrieb das Thema allgemeiner als Webressource. Der Herausgeber nannte Thema und Hub, der Abonnent schickte einen POST-Antrag, der Hub lieferte später per POST an die Rückrufadresse.

HTTP 202 Accepted klingt nach einem fertigen Geschäft. Die Empfehlung verlangte diese Antwort aber, wenn der Hub den Antrag entgegennehmen und bearbeiten konnte. Prüfung und Bestätigung folgten erst. Der Hub durfte bestimmte Themen oder Rückrufadressen nach eigener Richtlinie ablehnen. Er musste die Rückrufadresse herausfordern und die Antwort prüfen. Eingang, bestätigtes Abonnement und zugestellte Aktualisierung sind drei verschiedene Belege.

Hinzu kam eine Uhr. Der Entwurf von 2010 ließ befristete Abonnements zu und beschrieb eine automatische Rückfrage des Hubs zur Verlängerung. Die Empfehlung von 2018 verpflichtete Hubs, Ablaufzeiten durchzusetzen, und untersagte unbegrenzte Laufzeiten. Bei der Bestätigung teilte der Hub hub.lease_seconds mit; der Abonnent musste vor Ende erneut beantragen. Ein Feed konnte weiter öffentlich und aktuell sein, während ein säumiger Empfänger nicht länger per Push beliefert wurde.

Die Empfehlung erlaubte mehrere Hubs und unabhängige Betreiber. Der Herausgeber wählte, welche er auswies. Der ausgewählte Hub entschied über Annahme, prüfte Rückrufadressen, zählte Laufzeiten und organisierte Zustellungen. Der Herausgeber musste Änderungen an seine Hubs melden, wobei die genaue Methode den Beteiligten überlassen blieb. Der Hub holte den Inhalt und versandte ihn mit eigenen Grenzen für erneute Versuche. Veröffentlicht, gemeldet, beantragt, bestätigt, gültig und zugestellt waren sechs Zustände hinter dem Schlagwort Echtzeit.