Newsfeeds - Defective by Design?

Ein sehr großer Anteil meiner Freizeit geht mit dem Lesen von Newsfeeds drauf. Das kann ich mal als einfache Tatsache so stehen lassen. Ich sammle die Feed-Adressen von interessanten Blogs wie andere Briefmarken, sortiere aus was keine interessanten Daten/Artikel/Links mehr liefert, versehe die gelesenen Artikel mit Tags, gebe bestimmte Tags wieder als Newsfeed aus und antworte von Zeit zu Zeit auf Posts. Ich kann wohl kaum noch bestreiten dass in meinem Fall schon ein gewisses Suchtverhalten diesbezüglich vorliegt.

Bei all der Zeit, die ich mit diesen Techniken verbringe, bin ich natürlich immer auf der Suche nach Möglichkeiten wie sich das Ganze bequemer lösen lässt. Im Moment laufen fast alle meine Aktionen über Googles "Reader", was ein ziemlich guter Webbasierender Feedreader ist. Die Uptime-Statistiken sind natürlich wie bei allen anderen Google-Produkten für ein kostenloses Tool einfach traumhaft, auch treten eigentlich nie irgendwelche Performanceprobleme auf der Google-Seite auf und Funktionen hat das Ding eigentlich auch fast alles was ich mir wünschen kann.

Ab ein paar hundert Newsfeeds jedoch wird Reader immer umständlicher zu verwenden.
Die Seitenleiste mit der Feedübersicht lässt sich auf kleinen Bildschirmen schon lange nicht mehr sinnvoll benutzen und das verwalten der Feeds ist so ziemlich unbrauchbar. (Doppelt eingetragene URLs werden nicht automatisch entdeckt, die Feeds Tags zuzuordnen lässt sich nur sehr umständlich bewerkstelligen und Tags die einem ganzem Feed zugeordnet sind, kann man scheinbar überhaupt nicht von einem einzelnem Item entfernen.)

Auch zeigt sich bei privaten Newsfeeds sehr schnell, dass ein polling der Quelle alle 3 Stunden (wenn man der einzige Leser ist) ziemlich fern von jeder Aktualität ist. Auch 1 Stunde bei allen anderen Feeds ist nicht unbedingt die tollste Sache seit geschnitten Brot.

Lokale Software (Testergebnisse zu einzelnen Clients werden evtl. bald als Extraartikel folgen) hat es aber dennoch schwer mit derartigen Angeboten mitzuhalten. Natürlich würde ich am liebsten einen kleinen, schlanken Konsolen-Client verwenden und den RAM-fressenden Browser ganz deaktivieren. Leider bieten die wenigsten Newsfeeds den kompletten Inhalt gleich per Download an, also hat man dann den Konsolenclient UND den Browser offen. (Von eingebetteten Flash-Videos oder auch nur Bildern will ich lieber garnicht erst anfangen.)

Ein weiteres Problem mit lokaler Software zeigt sich ebenfalls erst wenn man ein paar Newsfeeds mehr als "normal" liest. Es macht verdammt wenig Spaß 1x die Stunde >300 XML-Dateien zu pollen. Dieser Effekt lässt sich verringern indem man die Dateien verteilt nacheinander abruft, mit einem Volumentarif würde ich mir das aber dennoch mehrmals überlegen. Außerdem sind wir bei 1 Abruf pro Stunde gerade erst bei der Aktualität von Google Reader angekommen, vielen wird aber etwas wie "alle 10min" viel eher logisch erscheinen.

Hier sehen wir dann auch bereits das was mich an RSS bzw. Atom am meisten stört.
Egal ob sich überhaupt etwas geändert hat und egal ob wir die letzten 10-50 Posts eh schon auf der Festplatte zwischengespeichert haben, wir laden jedes Mal alles in einer kompletten Datei aufs Neue herunter. Wenn der Newsfeed (wie eigentlich auch wünschenswert) dann auch noch den kompletten Postinhalt enthällt kommen da schnell ein paar hunder KB zusammen.

Besser wäre es z.B. schon eine Indexdatei zu basteln, die dann auf XML-Dateien mit den jeweiligen Inhalten für jeden Post verlinkt. Erstens könnte man so auf viel Overhead seitens der XML-Struktur in der Hauptdatei verzichten (evtl. könnte man sogar auf XML ganz verzichten, ein imho lohnendes Ziel). Zweitens würde es dies auch ermöglichen Änderungen der Quelle und ähnliches zu Indizieren.
Eine CSV-ähnliche Zeile mit <timestamp>,edit|new|deleted|blahfasel,<post-id>,<post-URL> würde pro Eintrag bereits reichen.

Aber warum an einer defekt designten Lösung herumfrickeln wenn es bereits bessere Ideen gibt? Die Einfachste Möglichkeit wäre wohl die Updates eher per per Push-Dienst auf den lokalen PC zu bekommen statt permanent nachsehen zu müssen ob neue Updates vorhanden sind. Eine weitere Möglichkeit sieht man bei diversen Web-Readern, es wird nur noch eine einzige Indexdatei für jeden Nutzer abgerufen, meist per AJAX, die schon sortiert die für den jeweiligen Nutzer interessanten Items enthällt.

Natürlich wäre ersteres eleganter, letzteres jedoch lässt sich offensichtlich einfacher realisieren ohne neben http noch andere Protokolle ins Spiel zu bringen (ansonsten gäbe es wohl auch endlos viele Lösungen, von denen jede besser ist als die aktuelle auf http-Basis).
Allerdings gibt es auch für die erste Version bereits Protokolle über die es sich recht einfach lösen lassen würde.

Meine aktuelle Lieblingsvariante ist wohl der Publish/Subscribe-Mechanismus welcher im Jabber-Protokoll integriert wurde. Dabei handelt es sich um eine Möglichkeit, auf einem beliebigen Pubsub-Server (ist in z.B. ejabberd bereits integriert, ein Beispiel wäre z.B. pubsub.jabber.ccc.de) in einer Struktur seine Updates an eine Node zu senden, von dort aus verteilt der Server dann automatisch die Informationen an alle Clients die sich eingetragen haben weiter.

Leider krankt Pubsub derzeit noch stark daran dass es keine wirklich ausgereifte Implementierung auf Clientseite gibt. Gajim unterstützt das XEP zwar scheinbar zu gewissen Werten (andere Clients scheinen afaik da noch überhaupt keine Anstrengungen zu unternehmen), es gibt aber immer wieder Probleme wenn man versucht es wirklich zu nutzen. In meinen Tests war es mir noch nicht möglich überhaupt eine Meldung von irgendeiner Pubsub-Node zu bekommen.

Auf der Serverseite sieht es theoretisch besser aus, z.B. besteht schon seit längerem ein Plugin für Wordpress, dass es recht einfach ermöglichen würde neue Posts oder Kommentare auch per Pubsub auszuliefern. Allerdings hängt dies auch wieder an den Clients etwas, die Serverseitigen Scripte kann man ja atm nur über die XML-Konsole testen, die einige Clients bieten. Hier sollte natürlich die Grundregel gelten dass man NIEMALS einen Menschen dazu zwingen sollte XML-Code zu tippen, in diesem Fall sogar Live mit einem Server zu reden. XML als "menschenlesbares" Datenformat ist wohl einer der Witze, die sich ein denkender Mensch nichtmal absichtlich hätte ausdenken können.

Alle aktuell verwendbaren Lösungen haben ohnehin offensichtlich das XML-Format gemeinsam. Für ein System das immer mehr und mehr Bandbreite schluckt, dessen Bereitstellung und Verarbeitung meiner Meinung nach in Zukunft immer wichtiger wird und dessen Inhalt meist nicht über <timestamp><autor><link><Datenpaket> hinausgeht sollte man sich evtl. doch besser etwas anderes einfallen lassen. Aber das ist mal wieder nur meine Meinung.

Randbemerkung: Während ich diesen Artikel geschrieben hab (dieser stellt mit 4 Tagen als Entwurf einen neuen, privaten Rekord dar) wurde das Thema bei einigen anderen Stellen angeschnitten, vor allem beziehe ich mich damit auf mehrere Diskussionen im IRC (kann ich euch leider nicht zum Nachlesen verlinken) als auch auf einen Beitrag von René, zu dem es teilweise sehr interessante Kommentare gab.