Ruckeln im RSS Räderwerk

Schon einmal diese kleinen orangen Icons gesehen?
Über zwei Jahre ist es her, dass Google seinen beliebten und weit verbreiteten RSS Reader eingestellt hat (Google Reader Alternativen bei Caschy). Inzwischen hatte ich mich mit Vienna RSS auf dem Mac, Inoreader und diversen Browser-Erweiterungen zum Abonnieren der Aktualisierungen angefreundet.

Nun gewinne ich das Gefühl, dass RSS im Netz – zumindest von den Großen – zunehmend stiefkindlich behandelt wird.
Wer nicht weiß, was es mit dieser Art von Site Summaries auf sich hat, sei wie immer auf den passenden Wikipedia Artikel verwiesen. (Und als Abschweifung auf die Geschichte von Aaron Swartz, der schon als Jugendlicher Koautor der RSS-Spezifikation 1.0 war.)

Ein spezieller Vorteil von RSS ist Syndication, vereinfacht gesagt eine Möglichkeit, Inhalte aus unterschiedlichen Quellen nahtlos zusammenzufügen.
Das machte mir mit Yahoo Pipes besonders Spaß. Yahoo Pipes wurde allerdings seit 01.11.2015 fast vollständig deaktiviert (nur hin und wieder tröpfelt etwas durch existierende Pipes).
Twitter hat bereits im Juni 2013 die Auslieferung per RSS eingestellt (lesenswert Dieter Bohn bei The Verge: Why RSS still matters).
Schließlich kommt auch der verunglückte Last.fm Relaunch (zunächst?) ohne RSS-Feeds, die für mich einen großen Teil des Charmes diese Musikdienstes ausgemacht haben.
Das hat mir meine ausgeklügelten RSS-Konstrukte ganz schön durcheinander gewürfelt. Und so weiter und so fort. Da geht es hin, das freie Web.

Google CDN für die Web App?

Na gut, also spiele ich diesen Hotfix ein. Es sollen eine Reihe von Problemen mit der Web-Anwendung behoben werden, außerdem besteht Hoffnung, dass die Anwendung im Browser auf den Clients flotter laufen wird. Nach dem Austausch der aktualisierten Dateien erscheint im Browser ein weißes Fenster. Was lief schief? Könnte es eine Rolle spielen, dass ich zunächst in einer virtuellen Maschine ohne Internetanbindung getestet habe? In der Tat möchte der Browser diesmal Daten von Google abrufen.
Als ich die ausgetauschte Web-Konfigurationsdatei mit der vorherigen Version vergleiche, kann ich eine kleine Änderung entdecken. In der neuen Fassung wird der Zugriff auf ein externes CDN vorgesehen.
Hm, Content Distribution Network, kennt doch jeder (zumindest die praktischen Auswirkungen). Typisches Beispiel: Akamai sorgt mit seinem CDN dafür, dass der Live-Stream oder das Update überall reibungslos ankommen. Millionen von Rechnern in aller Welt stürzen sich nicht über weite Wege auf einen überlasteten Update Server, sondern werden DNS-basiert auf den gewünschten Inhalt auf einem gut erreichbaren Server in ihrer Nähe geleitet.
Aber welchen Content soll das externe Google CDN unserer Anwendung bereitstellen? Unsere eigenen Individualdaten nicht, die sind nirgendwo gespiegelt; die Bildchen, die für die grafische Benutzeroberfläche benötigt werden sind zu klein, was denn sonst? Die Anwendung basiert auf HTLM5 und AJAX. Tatsächlich liefert das CDN Google Hosted Libraries in der Anwendung benötigte JavaScript Bibliotheken aus. (So etwas hätte es etwa auch von Microsoft gegeben.)
Die typischerweise benötigte jQuery Library hat eine Größe von etwa 250 KB. Das ist zwar in heutigen Netzwerken keine gewaltige Datenmenge, aber die Daten müssen eben auf jeden Client geladen werden, bevor für den Nutzer überhaupt etwas passiert. (Bei t3n gibt es sogar Tipps, wie man das Laden von jQuery durch Nutzung von nativem JavaScript vermeidet.)
Wie bei Google Public DNS fragt sich der besonders kritische Nutzer in Europa natürlich, aus welchem Grund das Unternehmen denn diese Dienstleistung unentgeltlich bereit stellt. Was passiert tatsächlich mit all Daten über Seitenaufrufe? Es ist müßig, darüber zu spekulieren.

Ebenso spannend ist wohl die Frage, ob oder wann es bei einer Anwendung sinnvoll sein kann, externe CDN-Dienste zu nutzen. Wenn regelmäßig von weit verteilten Orten auf einen Server zugegriffen werden soll, ist der Nutzen sicherlich schnell erkennbar (zum weiteren Vorteilen in dieser Konstellation siehe M. Kleine). Für eine Intranet-Anwendung erscheint diese Lösung eher ungeeignet. Oder? Man könnte vielleicht einen kleinen überlasteten Internet Information Server davor bewahren, sich zu bemühen Daten auszuliefern, die eh da draußen zu finden sind. Es ist auch nicht völlig ausgeschlossen, dass durch ungünstige Verkabelung von einem Client aus Google schneller zu erreichen ist, als der Server im Keller. Wer weiß.

Auf jeden Fall sollen man bei Rückgriff auf ein CDN nicht vergessen, dass von Zeit zu Zeit kein Internet greifbar ist (Offline Fallback beschrieben bei Scott Hanselman). In meinem praktischen Ausgangspunkt fehlte leider ein solcher Rückgriff auf die lokalen Ressourcen.

Externe JavaScript Bibliotheken

Externe JavaScript Bibliotheken