Subject: Weiterer RSS-Artikel (WIP)
From: Boris Kraut <[email-masked]>
To: undisclosed-recipients: ;
Date: Sun, 22 Apr 2012 00:20:22 +0200

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