1 From: Boris Kraut <krt@nurfuerspam.de>
\r
3 Date: Sun, 22 Apr 2012 00:20:22 +0200
\r
5 Message-ID: <20120421222022.14i0s6@silberbruch>
\r
8 To: undisclosed-recipients: ;
\r
9 Subject: Weiterer RSS-Artikel (WIP)
\r
11 Ende letzten Jahres war ich bei meillo und wir haben uns kurz ueber
\r
12 einen wahren Evergreen der Rubrik "kaputte Technologie" unterhalten,
\r
13 RSS. Er hat dazu dann auch nochwas geschrieben [0] und auch ich habe
\r
14 den folgenden Artikel angefangen, aber nie fertig gestellt.
\r
16 Vielleicht aktualisier ich ihn ja mal, vieleicht aber auch nicht,
\r
17 fuer den Moment gibt es neben dem RSS-Thema einfach auch nen kleinen
\r
18 Einblick in meine "Artikelschmiede".
\r
20 Warum gerade jetzt? Akuter Zeit- und Lustmangel, wobei meine Liste
\r
21 mit moeglichen Themen eigentlich gut gefuellt ist. Wie dem auch sie,
\r
25 Eigentlich habe ich meine Ansichten zum Thema Feeds ja hier schon
\r
26 mehrfach ausgebreitet, aber da ich letztens mit meillo [0] nochmals
\r
27 das Thema diskutiert habe und uns beiden ein paar Einsichten ge-
\r
28 kommen sind, die zwar bisher implizit mitgeschwungen sind, aber
\r
29 uns selbst wohl so nicht bewusst waren, moechte ich das Thema
\r
30 nochmals aufgreifen.
\r
32 Ausloeser war die Frage, was Feeds eigentlich sind und genau die
\r
33 moechte ich auch hier mal an den Anfang stellen. Schauen wir uns
\r
34 einfach mal die Namen der beiden haeufigsten Vertreter an: RSS,
\r
35 ausfuehrlich Really Simple Syndication, und Atom, genauer ASF --
\r
36 Atom Syndication Format. Beide Formate legen also wohl besonderen
\r
37 Wert auf "Syndication", was soviel wie "Zusammenlegung" bedeutet.
\r
38 Das hilft uns erstmal nicht viel weiter. Der Begriff selbst wird
\r
39 aber im Kontext von Print-Presse, Rundfunk und TV schon laenger
\r
40 benutzt und meint das zeitgleiche (bzw. -nahe) Veroeffentlichen
\r
41 eines Artikels oder einer Sendung in mehreren Zeitungen oder auf
\r
44 Im Web wird darunter prinzipiell das Bereitstellen der Inhalte
\r
45 in einem standardisierten Austauschformat verstanden, meist eben
\r
46 RSS oder Atom. Auch wenn gerade RSS mit einem ziemlichen Wild-
\r
47 wuchs aufwartet, kann man durchaus sagen, dass die Formate ihre
\r
48 Zielsetzung durchaus erreicht haben. Doch wie sieht die Zukunft
\r
49 aus? Natuerlich schreitet auch die Entwicklung der Formate voran,
\r
50 aber brauchen wir das wirklich? Ganz neben bei hat HTML5 naemlich
\r
51 das semantische Web um einige Elemente erweitert, die prinzipiell
\r
52 eine aehnliche Nutzung erlauben -- ob ich mir nun "entry"- oder
\r
53 "article"-Elemente aus einem Stueck (Pseudo-) XML herauspopeln
\r
54 muss, ist ja eigentlich egal.
\r
56 Der naechste Schritt in der Kette ist, unseren standardisierten
\r
57 Artikel zeitnah zu verteilen. Und genau hier kommen ernsthafte
\r
58 Probleme zum Vorschrein:
\r
60 1) Ziel ist es einen bestimmten Inhalt an moeglichst viele Nutzer
\r
61 zu bringen, der Weg dafuer sollte es sein einen Artikel an
\r
62 moeglichst viele Sender zu verteilen; der Empfaenger spielte
\r
63 erstmal keine Rolle. Ich weiss nicht, ob bei Web-Syndication
\r
64 schon von Anfang an klar war, an welche Zielgruppe -- Nutzer
\r
65 (bzw. dessen Feedreader als Art persoenliche Zeitung) oder
\r
66 andere Webseiten -- sich ein Feed richtet. Ich finde das
\r
67 macht einen grossen Unterschied, gerade beim Thema...
\r
69 2) ... "zeitnahe" Veroeffentlichung. Denn bisher ist der "modus
\r
70 operandi" per Polling immer bei der Quelle nachzufragen, ob
\r
71 es neue Eintraege gibt. Dadurch ensteht unnoetiger Overhead,
\r
72 der gerade bei der Zielgruppe "Nutzer" schnell ansteigt.
\r
74 Zwar bieten Feeds ein Feld fuer die letzte Aktualisierung an,
\r
75 aber um das rauszufinden reicht es ja schon vorher auf die
\r
76 Last-Modified Kopfzeile von HTTP zu schauen. Generell waere
\r
77 hier eine Push-Technologie wuenschenswert.
\r
79 Prinzipiell gibt es das sogar schon, denn der Atom-Standard
\r
80 definiert nicht nur das ASF, sondern auch das Atom Publishing
\r
81 Protocol (APP bzw. AtomPub). Letzteres benutzt HTTP um Entries
\r
82 zu veroeffentlichen, zu veraendern und zu loeschen. Damit
\r
83 koennte man sicher auch einen Artikel an mehrere Empfaenger
\r
84 pushen. Wobei man natuerlich ein UID-Kuddelmuddel vermeiden
\r
87 Aber selbst mit Push bleibt die Frage, ob man hier den ganzen
\r
88 Content mitausliefern muss? Zwar sollte alles in einem offen
\r
89 standardisierten Format abrufbar sein, aber allein fuer die
\r
90 Benachrichtigung, dass es ein Update gibt, braucht man das
\r
91 nicht. Die Entscheidung macht sich auch hier wieder an der
\r
92 in (1) genannten Frage fest: Wer ist die Zielgruppe?
\r
94 Auch im Web wird die Push/Pull-Frage natuerlich diskutiert;
\r
95 als eine moegliche Loesung will sich PubSubHubbub vorstellen.
\r
96 Dabei kann ein Feed Verteiler-Server announcen, auf denen
\r
97 sich der Nutzer (bzw. dessen Client) eintragen lassen kann.
\r
98 Gibt es einen neuen Artikel, benachrichtet die Quelle diese
\r
99 Hubs, die sich dann die Aenderung per Pull holen. Die Nutzer
\r
100 selbst werden dann von diesen Hubs mit den relevanten News
\r
103 Der Gedanke von Hubs als Sammelstellen ist natuerlich nicht
\r
104 neu: Bei Feeds gibt es schon lange sog. "Planeten", die als
\r
105 thematische Zusammenstellung von mehreren Feeds fungieren.
\r
106 Die Inhalte selbst werden aber meist auch per Pull geholt
\r
107 und auch per Pull wieder von den Nutzern abgefragt.
\r
109 Aber auch noch frueher war das Sammeln an zentralen Stellen
\r
110 gaengige Praxis, wenn nicht so gar noetig -- RFC 977:
\r
112 > Clearly, a worthwhile reduction of the amount of these
\r
113 > resources used can be achieved if articles are stored
\r
114 > in a central database on the receiving host instead of
\r
115 > in each subscriber's mailbox. The USENET news system
\r
116 > provides a method of doing just this.
\r
118 Wohl bedingt durch die aufkommenden HomePCs und deren kosten-
\r
119 intensive Waehlverbindungen hat man dann doch wieder begonnen
\r
120 die News von den Sammelstellen per Pull herunterzuladen, von
\r
123 ...scheint sich Pull generell nicht wirklich vermeiden zu
\r
124 lassen, der User wird derzeit einfach derjenige sein, der
\r
125 den letzten Download auf sein eigenes Device anstoesst. Denn
\r
126 leider hat die Entwicklung der letzten Jahre zu einem stark
\r
127 asymmetrischen Netz gefuehrt: Maechtige, staendig verfuegbare
\r
128 Server mit prinzipiell dummen Clients. Selbst wenn man seinen
\r
129 eigenen Server betreibt, werden die wenigsten direkt darauf
\r
130 arbeiten sondern eben einen (oder gar mehrere) Clients ver-
\r
131 wernden, um auf den Server zuzugreifen. Es sind also die
\r
132 Clients die erstmal die Kommunikation anstossen muessen, man
\r
133 hat also fast immer -- d.h. selbst wenn bis zum eigenen Serer
\r
134 alles per Push geliefert wird -- einen Pull-Vorgang. Das ist
\r
135 aber auch nicht schlimm, denn es geht ja weniger um "pull ist
\r
136 schlecht" und "push ist gut", sondern um eine effiziente und
\r
137 effektive oder gar natuerliche Netz(aus)nutzung.
\r
139 3) Aus (1) ergibt sich allerdings noch ein weiterer Punkt, denn
\r
140 die Annahme, dass es darum geht Inhalt moeglichst weit zu
\r
141 streuen, trifft meist nicht mehr zu. Vielen Anbietern geht
\r
142 es eher darum, moeglichst viele Nutzer auf ihre Seite zu
\r
143 locken, um damit -- bspw. ueber Werbung -- zu verdienen. Der
\r
144 eigentliche Inhalt ist da nur Mittel zum Zweck. Von daher
\r
145 erstaunt es nicht, wenn man statt dem Inhalt nur kleine
\r
146 Teaser oder Beschreibungen des Inhalts in den Feed packt --
\r
147 im schlimmsten Fall gar nur die Links.
\r
149 Anmerkung: Auch ich veroeffentliche im Feed nur die Links,
\r
150 was aber an meiner Faulheit und genrell sehr
\r
151 stiefmuetterlichen Behandlung des Feeds liegt;
\r
152 meine Mail-Abonnenten bekommen natuerlich den
\r
155 4) Und selbst wenn ein Full-Content-Feed angeboten wird, so
\r
156 wird -- bei der Zielgruppe "andere Website" -- meist nicht
\r
157 eine Weiterveroeffentlichung vorgenommen, sondern ein eigener
\r
158 Artikel zum selben Thema geschrieben bzw. ein wortgleicher
\r
159 Artikel mit neuer UID veroeffentlicht. Problematisch ist das
\r
160 dann, wenn der Nutzer dann sowohl die Original-Quelle wie
\r
161 auch mehrere Zweitveroeffentlichung liest: Er muss sich durch
\r
162 zig Artikel klicken, die eigentlich keine neuen Informationen
\r
163 enthalten. Seufz. Dabei gibt es mit Atom doch durchaus gute
\r
164 Moeglichkeiten einen fremden Artikel zu uebernehmen, ggf. mit
\r
165 einer eigenen Meinung zu versehen oder nur eine inhaltliche
\r
166 Naehe zu anderen Artikeln zu markieren. Auch auf Seiten der
\r
167 "Zweitverwerter" geht es also nicht um den Inhalt, sondern
\r
168 um Klicks auf die eigene Website.
\r
170 - Wer triggert das veroeffentlichen an?
\r
174 5) Filterung ist ein weiteres Problem, das man gerne den Feeds
\r
175 anlastet und tatsaechlich bringen sie selbst ueberhaupt keine
\r
176 Moeglichkeiten mit, zu filtern... oder doch? Und wenn nicht,
\r
177 ist Filtern ueberhaupt ihre Aufgabe?
\r
179 Nun, abgesehen vom Anbietern von verschiedenen Feeds, bietet
\r
180 zumindest das Atom-Fromat explizit an, ein Entry mit Tags bzw.
\r
181 Schluesselwoertern zu versehen, eine Eigenschaft, die auch
\r
182 Mails haben (und die leider nahezu nie genutzt wird). Daraus
\r
183 lassen sich prinzipiell wirksame Filter bauen, aber leider
\r
184 sind die wenigsten Feeds mit wirklich brauchbaren Tags aus-
\r
185 gestattet, noch sind die Feedreader generell fuer maechtige
\r
186 Filter zu gerauchen.
\r
188 - Reduzierung des Transfervolumens
\r
189 - Uebersicht fuer die Nutzer
\r
190 - ...aber: Wer filtert (Benutzer, Autor, Google, Relays..)?
\r
192 - Alles einsammeln und lokal filtern (Anzeige)?
\r
193 - Nur das uebertragen was man lesen will?
\r
194 - Soziale Filter -- Twitter, G+ und Co.
\r
196 - Suchmaschinen-Filter
\r
197 - Dezentrale-Freunde-Suchcluster
\r
199 - SQL fuer das komplette Web :)
\r
201 - https://projects.webvariants.de/projects/tagolution/wiki
\r
202 - http://goeoeck.net/wiki/Tagolution#Tagolution
\r
203 - Hatte ich im DNS-Rant nicht schon erwaehnt einfach nur
\r
204 noch lange uniq hashes und tags, statt namen zu verwenden?
\r
209 - aus filter/suche => datenschutzproblem: wer sucht was?
\r
210 - oder gar user subscriber: wer aboniert was, wer sind
\r
211 meine nutzer (auch bei mail-newsletter)
\r
217 # Gedanken und Ideen:
\r
218 # rss: feeds sind nicht die antwort. das problem was
\r
219 # sie geloest haben, war ein standard zum nachrichten
\r
220 # austausch zu schaffen. ich mag das, aber sein wir
\r
221 # ehrlich: wir haben jetzt html5 ein article oder atom
\r
222 # feed.. prinzipiell das selbe . aber aber aber..
\r
223 # feeds machen ja nur das neue: falsch. feeds werden
\r
224 # regelmaessig gepollt und der client entscheidet das
\r
225 # was neu ist. wir koennen es bei feeds nur besser
\r
226 # automatisieren... wirklich? warum nicht einfach
\r
227 # last-change der website? wobei nicht pollen
\r
228 # eigentlich der bessere weg ist: push ist die loesung,
\r
229 # websites sollen mir bescheid sagen, wenn es was neues
\r
230 # gibt. das muss nicht heissen, dass sie den content
\r
231 # gleich mitschicken. sobald ich angetriggert wurde
\r
232 # kann ich mir ja die website anguggen (oder einem
\r
233 # proramm sagen mit die articles der website auszulesen und
\r
234 # lokale einzupflegen).
\r
236 # feeds waraen nur noetig, weil html es nicht konnte.
\r
238 # eigener rss-feed: zu gross; browser rendern text statt rss/xml
\r
243 [0] http://marmaro.de/lue/txt/2011-12-10.txt
\r
projects / krt-msg / blob