From: Boris Kraut Organization: Date: Sun, 22 Apr 2012 00:20:22 +0200 Category: Message-ID: <20120421222022.14i0s6@silberbruch> Keywords: Comments: To: undisclosed-recipients: ; Subject: Weiterer RSS-Artikel (WIP) Ende letzten Jahres war ich bei meillo und wir haben uns kurz ueber einen wahren Evergreen der Rubrik "kaputte Technologie" unterhalten, RSS. Er hat dazu dann auch nochwas geschrieben [0] und auch ich habe den folgenden Artikel angefangen, aber nie fertig gestellt. Vielleicht aktualisier ich ihn ja mal, vieleicht aber auch nicht, fuer den Moment gibt es neben dem RSS-Thema einfach auch nen kleinen Einblick in meine "Artikelschmiede". Warum gerade jetzt? Akuter Zeit- und Lustmangel, wobei meine Liste mit moeglichen Themen eigentlich gut gefuellt ist. Wie dem auch sie, hier der Artikel: Eigentlich habe ich meine Ansichten zum Thema Feeds ja hier schon mehrfach ausgebreitet, aber da ich letztens mit meillo [0] nochmals das Thema diskutiert habe und uns beiden ein paar Einsichten ge- kommen sind, die zwar bisher implizit mitgeschwungen sind, aber uns selbst wohl so nicht bewusst waren, moechte ich das Thema nochmals aufgreifen. Ausloeser war die Frage, was Feeds eigentlich sind und genau die moechte ich auch hier mal an den Anfang stellen. Schauen wir uns einfach mal die Namen der beiden haeufigsten Vertreter an: RSS, ausfuehrlich Really Simple Syndication, und Atom, genauer ASF -- Atom Syndication Format. Beide Formate legen also wohl besonderen Wert auf "Syndication", was soviel wie "Zusammenlegung" bedeutet. Das hilft uns erstmal nicht viel weiter. Der Begriff selbst wird aber im Kontext von Print-Presse, Rundfunk und TV schon laenger benutzt und meint das zeitgleiche (bzw. -nahe) Veroeffentlichen eines Artikels oder einer Sendung in mehreren Zeitungen oder auf mehreren Sendern. Im Web wird darunter prinzipiell das Bereitstellen der Inhalte in einem standardisierten Austauschformat verstanden, meist eben RSS oder Atom. Auch wenn gerade RSS mit einem ziemlichen Wild- wuchs aufwartet, kann man durchaus sagen, dass die Formate ihre Zielsetzung durchaus erreicht haben. Doch wie sieht die Zukunft aus? Natuerlich schreitet auch die Entwicklung der Formate voran, aber brauchen wir das wirklich? Ganz neben bei hat HTML5 naemlich das semantische Web um einige Elemente erweitert, die prinzipiell eine aehnliche Nutzung erlauben -- ob ich mir nun "entry"- oder "article"-Elemente aus einem Stueck (Pseudo-) XML herauspopeln muss, ist ja eigentlich egal. Der naechste Schritt in der Kette ist, unseren standardisierten Artikel zeitnah zu verteilen. Und genau hier kommen ernsthafte Probleme zum Vorschrein: 1) Ziel ist es einen bestimmten Inhalt an moeglichst viele Nutzer zu bringen, der Weg dafuer sollte es sein einen Artikel an moeglichst viele Sender zu verteilen; der Empfaenger spielte erstmal keine Rolle. Ich weiss nicht, ob bei Web-Syndication schon von Anfang an klar war, an welche Zielgruppe -- Nutzer (bzw. dessen Feedreader als Art persoenliche Zeitung) oder andere Webseiten -- sich ein Feed richtet. Ich finde das macht einen grossen Unterschied, gerade beim Thema... 2) ... "zeitnahe" Veroeffentlichung. Denn bisher ist der "modus operandi" per Polling immer bei der Quelle nachzufragen, ob es neue Eintraege gibt. Dadurch ensteht unnoetiger Overhead, der gerade bei der Zielgruppe "Nutzer" schnell ansteigt. Zwar bieten Feeds ein Feld fuer die letzte Aktualisierung an, aber um das rauszufinden reicht es ja schon vorher auf die Last-Modified Kopfzeile von HTTP zu schauen. Generell waere hier eine Push-Technologie wuenschenswert. Prinzipiell gibt es das sogar schon, denn der Atom-Standard definiert nicht nur das ASF, sondern auch das Atom Publishing Protocol (APP bzw. AtomPub). Letzteres benutzt HTTP um Entries zu veroeffentlichen, zu veraendern und zu loeschen. Damit koennte man sicher auch einen Artikel an mehrere Empfaenger pushen. Wobei man natuerlich ein UID-Kuddelmuddel vermeiden sollte. Aber selbst mit Push bleibt die Frage, ob man hier den ganzen Content mitausliefern muss? Zwar sollte alles in einem offen standardisierten Format abrufbar sein, aber allein fuer die Benachrichtigung, dass es ein Update gibt, braucht man das nicht. Die Entscheidung macht sich auch hier wieder an der in (1) genannten Frage fest: Wer ist die Zielgruppe? Auch im Web wird die Push/Pull-Frage natuerlich diskutiert; als eine moegliche Loesung will sich PubSubHubbub vorstellen. Dabei kann ein Feed Verteiler-Server announcen, auf denen sich der Nutzer (bzw. dessen Client) eintragen lassen kann. Gibt es einen neuen Artikel, benachrichtet die Quelle diese Hubs, die sich dann die Aenderung per Pull holen. Die Nutzer selbst werden dann von diesen Hubs mit den relevanten News versorgt. Der Gedanke von Hubs als Sammelstellen ist natuerlich nicht neu: Bei Feeds gibt es schon lange sog. "Planeten", die als thematische Zusammenstellung von mehreren Feeds fungieren. Die Inhalte selbst werden aber meist auch per Pull geholt und auch per Pull wieder von den Nutzern abgefragt. Aber auch noch frueher war das Sammeln an zentralen Stellen gaengige Praxis, wenn nicht so gar noetig -- RFC 977: > Clearly, a worthwhile reduction of the amount of these > resources used can be achieved if articles are stored > in a central database on the receiving host instead of > in each subscriber's mailbox. The USENET news system > provides a method of doing just this. Wohl bedingt durch die aufkommenden HomePCs und deren kosten- intensive Waehlverbindungen hat man dann doch wieder begonnen die News von den Sammelstellen per Pull herunterzuladen, von daher... ...scheint sich Pull generell nicht wirklich vermeiden zu lassen, der User wird derzeit einfach derjenige sein, der den letzten Download auf sein eigenes Device anstoesst. Denn leider hat die Entwicklung der letzten Jahre zu einem stark asymmetrischen Netz gefuehrt: Maechtige, staendig verfuegbare Server mit prinzipiell dummen Clients. Selbst wenn man seinen eigenen Server betreibt, werden die wenigsten direkt darauf arbeiten sondern eben einen (oder gar mehrere) Clients ver- wernden, um auf den Server zuzugreifen. Es sind also die Clients die erstmal die Kommunikation anstossen muessen, man hat also fast immer -- d.h. selbst wenn bis zum eigenen Serer alles per Push geliefert wird -- einen Pull-Vorgang. Das ist aber auch nicht schlimm, denn es geht ja weniger um "pull ist schlecht" und "push ist gut", sondern um eine effiziente und effektive oder gar natuerliche Netz(aus)nutzung. 3) Aus (1) ergibt sich allerdings noch ein weiterer Punkt, denn die Annahme, dass es darum geht Inhalt moeglichst weit zu streuen, trifft meist nicht mehr zu. Vielen Anbietern geht es eher darum, moeglichst viele Nutzer auf ihre Seite zu locken, um damit -- bspw. ueber Werbung -- zu verdienen. Der eigentliche Inhalt ist da nur Mittel zum Zweck. Von daher erstaunt es nicht, wenn man statt dem Inhalt nur kleine Teaser oder Beschreibungen des Inhalts in den Feed packt -- im schlimmsten Fall gar nur die Links. Anmerkung: Auch ich veroeffentliche im Feed nur die Links, was aber an meiner Faulheit und genrell sehr stiefmuetterlichen Behandlung des Feeds liegt; meine Mail-Abonnenten bekommen natuerlich den Inhalt frei Haus. 4) Und selbst wenn ein Full-Content-Feed angeboten wird, so wird -- bei der Zielgruppe "andere Website" -- meist nicht eine Weiterveroeffentlichung vorgenommen, sondern ein eigener Artikel zum selben Thema geschrieben bzw. ein wortgleicher Artikel mit neuer UID veroeffentlicht. Problematisch ist das dann, wenn der Nutzer dann sowohl die Original-Quelle wie auch mehrere Zweitveroeffentlichung liest: Er muss sich durch zig Artikel klicken, die eigentlich keine neuen Informationen enthalten. Seufz. Dabei gibt es mit Atom doch durchaus gute Moeglichkeiten einen fremden Artikel zu uebernehmen, ggf. mit einer eigenen Meinung zu versehen oder nur eine inhaltliche Naehe zu anderen Artikeln zu markieren. Auch auf Seiten der "Zweitverwerter" geht es also nicht um den Inhalt, sondern um Klicks auf die eigene Website. - Wer triggert das veroeffentlichen an? 5) Filterung ist ein weiteres Problem, das man gerne den Feeds anlastet und tatsaechlich bringen sie selbst ueberhaupt keine Moeglichkeiten mit, zu filtern... oder doch? Und wenn nicht, ist Filtern ueberhaupt ihre Aufgabe? Nun, abgesehen vom Anbietern von verschiedenen Feeds, bietet zumindest das Atom-Fromat explizit an, ein Entry mit Tags bzw. Schluesselwoertern zu versehen, eine Eigenschaft, die auch Mails haben (und die leider nahezu nie genutzt wird). Daraus lassen sich prinzipiell wirksame Filter bauen, aber leider sind die wenigsten Feeds mit wirklich brauchbaren Tags aus- gestattet, noch sind die Feedreader generell fuer maechtige Filter zu gerauchen. - Reduzierung des Transfervolumens - Uebersicht fuer die Nutzer - ...aber: Wer filtert (Benutzer, Autor, Google, Relays..)? - Wo filtert man? - Alles einsammeln und lokal filtern (Anzeige)? - Nur das uebertragen was man lesen will? - Soziale Filter -- Twitter, G+ und Co. - Filter Bubble - Suchmaschinen-Filter - Dezentrale-Freunde-Suchcluster - yacy.net - SQL fuer das komplette Web :) - Tagolution - https://projects.webvariants.de/projects/tagolution/wiki - http://goeoeck.net/wiki/Tagolution#Tagolution - Hatte ich im DNS-Rant nicht schon erwaehnt einfach nur noch lange uniq hashes und tags, statt namen zu verwenden? - 6) Datenschutz - aus filter/suche => datenschutzproblem: wer sucht was? - oder gar user subscriber: wer aboniert was, wer sind meine nutzer (auch bei mail-newsletter) - rdf site summary # Gedanken und Ideen: # rss: feeds sind nicht die antwort. das problem was # sie geloest haben, war ein standard zum nachrichten # austausch zu schaffen. ich mag das, aber sein wir # ehrlich: wir haben jetzt html5 ein article oder atom # feed.. prinzipiell das selbe . aber aber aber.. # feeds machen ja nur das neue: falsch. feeds werden # regelmaessig gepollt und der client entscheidet das # was neu ist. wir koennen es bei feeds nur besser # automatisieren... wirklich? warum nicht einfach # last-change der website? wobei nicht pollen # eigentlich der bessere weg ist: push ist die loesung, # websites sollen mir bescheid sagen, wenn es was neues # gibt. das muss nicht heissen, dass sie den content # gleich mitschicken. sobald ich angetriggert wurde # kann ich mir ja die website anguggen (oder einem # proramm sagen mit die articles der website auszulesen und # lokale einzupflegen). # # feeds waraen nur noetig, weil html es nicht konnte. # # eigener rss-feed: zu gross; browser rendern text statt rss/xml [0] http://marmaro.de/lue/txt/2011-12-10.txt