Im Rahmen der Implementierung von Pingbacks in diesem Blog und fehlender Libraries für Python, die auch auf der AppEngine funktionieren, hab ich Pingbacks nach der Spezifikation implementiert.

In dem Zuge bekam ich das Gefühl, dass Pingback irgendwie eine Fehlentwicklung ist. Da wäre z.B. Auto-Discovery. Die XML-RPC-URL über einen HEAD-Aufruf zu holen finde ich noch recht legitim. Aber als Alternative HTML zu parsen und zu verlangen, dass der Meta-Tag innerhalb der ersten 5 kB des Dokuments vorkommen, ist nahezu frech. Der angepingte Server hat ein ähnliches Problem. Er muss (optional, aber um ordentliche Pingbacks in Blogbeiträgen anzeigen zu lassen, unumgänglich) HTML parsen, um herauszufinden, ob die gepingte URL wirklich in dem Dokument vorkommt und auch, um sich den Titel der Seite zu holen.

Als Gegensatz dazu gibt es Trackbacks. Da werden Quell-URL, Titel und ein kleiner Abschnitt des Textes bereits beim Ping mitgesandt und können vom Moderator bestätigt werden. Mein Problem mit dem Parsen ist nämlich, dass es in den meisten Fällen syncron passiert, da man, wie man das schon in der Spezifikation sieht, entsprechende Fehlercodes zurückgeben muss, wenn etwas schief läuft, wie z.B. dass die angepingte URL gar nicht im Quell-Dokument vorkommt.

Realitätscheck: Gehen wir mal von einem mittelgut besuchten Blog aus. Der Blogbeitrag wird gepublished und diverse Dienste angepingt (pingomatic, Pubsubhubbub, Yahoo, usw.), die widerum die eigene Seite aufrufen und auch die aktualisierten Feeds checken. Hinzu kommt der automatische eigene Tweet, der auch nochmal 20-30 Leute auf das Blog schickt. Jetzt kommt der Pingback an ca. 3 Links, die sich im Text befinden. Das Blog ist jetzt etwas unter Spannung und die Seiten werden erst nach 3-5 Sekunden ausgeliefert. Aus Skalierungsgründen haben viele Pingback-Implementierungen einen Timeout von 2-4 Sekunden für Requests eingestellt. Die angepingte Seite versucht also jetzt auch das pingende, etwas belastete Blog aufzurufen und bekommt im Zweifel einen Timeout nach 3 Sekunden. Schade nur, dass in diesem Moment das pingende Blog eine Fehlermeldung zurückbekommt und es höchstwahrscheinlich nicht nochmal probiert.
Meine Implementierung versucht den Ablauf asyncron zu halten. Er nimmt den Ping erstmal entgegen. Wenn der Ping in keinem gültigen Format gesandt wird, bekommt er einen Generic-Error (0), ansonsten immer ein OK. Danach wird drei mal versucht, die Seite aufzurufen und zu parsen und dann erst aufgegeben. Diese Methode skaliert deutlich besser, ist aber leider in der Spezifikation nicht vorgesehen. Das ist wirklich schade und schon ein großer Überlegungsfehler.

Andere Schwäche: Der Mix. Es muss ein XML-RPC-Request geschickt werden. Alle Responses sind dann nicht mehr XML-RPC sondern String-Responses. Das ist sehr inkonsistent und wird begründet mit der Einfachheit, so wenige Libraries bei der Implementierung benötigen zu wollen. Aber dann hätte ja auch ein PUT oder POST-Request gereicht, dem man z.B. sourceURI und targetURI als Parameter hätte mitgeben können. Auch, dass man die Parameter-Reihenfolge im XML-RPC einhalten muss und nicht die namentlichen Parameter-Angaben gewählt hat, zeigt, dass man nicht darauf bedacht war, fehlertolerant zu sein.