Rechtsruck: Deutschland 2015

[krt-msg] / 2007-10-08T00:00:00Z.msg

From: Boris Kraut <krt@nurfuerspam.de>\r
Date: Mon, 08 Oct 2007 00:00:00 +0000\r
Category: \r
Sender: \r
Message-ID: <20071008000000.H1kl4T@silberbruch>  \r
References: \r
Keywords: \r
Comments: \r
To: undisclosed-recipients: ;\r
Subject: RSS, Feeds und Web2.0\r
\r
\r
i) Really Sucking Syndication\r
ii) Really Sucking Syndication Revised\r
iii) Reinventing the wheel - Auf der Suche nach dem Zen des Bloggens\r
\r
\r
Really Sucking Syndication\r
--------------------------\r
\r
Podcasts nutzen sie, Blogs nutzen sie, Webzeitungen nutzen sie. Es scheint,\r
als ob kaum noch eine Internetseite, die etwas auf sich haelt, ohne auskommen\r
koennte. Die Rede ist von sogenannten Webfeeds. Webfeeds, das sind im Grunde\r
meist einfache XML-Dateien, die nichts anderes beinhalten, als eine\r
Auflistung von Eintraegen, wie beispielsweise News-Meldungen, Blogposts oder\r
eben neuen Audiodateien. Der Anbieter sorgt dafuer, dass diese Feeds immer\r
korrekt bestueckt sind und der geneigte Leser brauch sie nur in einem\r
speziellen Programm diese Feed-Datei abonieren, damit er immer weiss, was\r
auf der jeweiligen Webseite gerade laeuft. Neben dem Link zur Meldung sind\r
meist auch nuetzliche Informationen ueber den Autor, das Veroeffentlichngsdatum\r
und den Inhalt im Feed enthalten. Klingt einfach, kling gut, oder?\r
\r
Die Idee hinter Feeds ist ja eigentlich nicht schlecht, nein, im Gegenteil,\r
sie ist sehr gut. Sie ist sogar so gut, dass man sie schon mehrfach in der\r
Geschichte hatten. Frueher nutzte man so etwas wie eine Index-Datei,\r
Directory-Listing oder Plaintext fuer sowas, aber mit der Zeit wurden diese\r
immer mehr von grafikgeilen Webdesignern, Werbeevangelisten und\r
selbsternannten SEO-Koenigen missbraucht und ihrer eigentlichen Funktion\r
beraubt. Zwar sahen die neuen Index-Seiten zwar immer besonders schoen aus,\r
doch wurden beeintraechtigte Menschen, Computer und auch einige normale\r
Benutzer einfach ausser Acht gelassen. Es musste also ein neuer Standard\r
her, bei dem man diesmal alles richtig machen wollte und dem zusaetzlich\r
viele nuetzliche Verbesserungen einfliessen sollten...\r
\r
Nun, es ist nicht ganz so gekommen. Statt einem gueltigen Standard, haben wir\r
derer inzwischen mehr als neun, die natuerlich alle untereinander nicht\r
kompatibel sind. Zudem demontieren die oben genannten Gruppierungen auch\r
diese neue Technologie, indem sie inzwischen auch ganze Artikel in den\r
Feed packen oder mit ekelhafter HTML-Formatiererei versuchen ein\r
Alleinstellungsmerkmal zu erhaschen. Inzwischen hat sich neben den\r
verschiedenen RSS-Derivaten zum Glueck eine Gruppe zusammengefunden, die einen\r
neuen, einheitlichen Standard schaffen will. Unter der RFC 4287 [1] wurde bei\r
der IETF ein Entwurf fuer den ATOM-Feed eingereicht, der hoffentlich bald zum\r
Standard erkoren wird.\r
\r
Ich fuer meinen Teil werde bis dahin jedenfalls keinen Feed anbieten. Wer\r
wissen will, was auf meiner Webseite passiert, darf sich gerne die Zeit\r
nehmen, sie zu besuchen. Auch ein Script zu schreiben, dass sich meine\r
Index-Datei herunterlaedt, die URLs vervollstaendigt und eventuell noch ein\r
paar Design-AEnderungen durchfuehrt sollte niemanden ueberfordern. Tut mir\r
leid, dass ich bei diesem Artikel hier eigentlich nur rumgemault hab, aber\r
ich habe mich am Wochenende deswegen wirklich aufgeregt und wollte meinem\r
AErger mal Luft machen. Weitere Informationen findet ihr auf den\r
folgenden Seiten:\r
\r
- [1] http://tools.ietf.org/html/rfc4287\r
- [2] http://diveintomark.org/archives/2004/05/27/howto-atom-linkblog\r
- [3] http://diveintomark.org/archives/2004/02/04/incompatible-rss\r
- [4] http://en.wikipedia.org/wiki/Atom_(standard)\r
- [5] http://de.wikipedia.org/wiki/Atom_(Format)\r
- [6] http://de.wikipedia.org/wiki/Resource_Description_Framework\r
- [7] http://en.wikipedia.org/wiki/RSS\r
- [8] http://de.wikipedia.org/wiki/RSS\r
\r
Nachtrag: Inzwischen habe ich den Folgeartikel "Really Sucking Syndication\r
Revised" geschrieben, indem ich ein etwas differenzierteres Bild von\r
Feeds zeichne.\r
\r
\r
Really Sucking Syndication Revised\r
----------------------------------\r
\r
Letztes Jahr habe ich ja meinem Unmut ueber Webfeeds schon einmal Luft\r
gemacht, doch inzwischen muss ich zugeben, dass es nicht damit getan\r
ist, Feeds einfach zu verdammen.\r
\r
Die Probleme\r
~~~~~~~~~~~~\r
\r
Die Grundprobleme sind natuerlich geblieben. Auch wenn sich Atom [1] 1.0 als\r
proposed standard zunehmender Beliebtheit erfreut, gibt es immer noch viel\r
zu viele Feeds die auf irgend einem Pseudostandard beruhen in den dann noch\r
eigene Erweiterungen gewurstet werden.\r
\r
Zudem sind Feeds durch die vielen teils nutzlosen Metainformationen einfach\r
nur zu aufgedunsen. Klar ist die Groesse in Zeiten von 16Mbit auf dem\r
Downstream kaum noch ein Argument, doch fuer die zunehmende Zahl an mobilen\r
Endgeraeten mit sehr geringer Bandbreite ist jedes Kilobyte, dass vergeudet\r
wird, zu viel. Auch darf man nicht annehmen, dass Breitbandanschluesse\r
inzwischen normal sind. Es gibt noch genuegend Gegenden, in denen man mit\r
56k-Modem oder ISDN ins Internet geht.\r
\r
Ein weiteres Problem ist wie immer der Missbrauch der Technologie. Nicht\r
alles, was man machen kann, ist auch gut. So kann es durchaus von Vorteil\r
sein, wenn man in die Beschreibung eines Artikels oder den Artikel selbst\r
im Feed mit Markup versieht, um das Lesen angenehmer zu machen. Nur muss\r
man hier zwei Dinge beachten: Zum einen muss klar sein, wo HTML verwendet\r
wird und wo nicht. Generell sind alle Inhalte Klartext und nur wenn man es\r
vorher explizit angibt, darf man HTML verwenden. Diese explizite Angabe\r
wird aber nicht von allen Feed-Formaten unterstuetzt, so dass es viel zu\r
viele Feeds gibt, die darauf hoffen, dass der Newsreader das schon per\r
Autosensing herausfindet. Das ist absolut daneben! Zum anderen sollte man\r
sich daran halten, dass weniger oft mehr ist. In einem Feed bitte kein\r
JavaScript, Grafiken oder explizite Formatierungsangaben verwenden. JScript\r
ist sowieso die Geisel der Menschheit, Grafiken sorgen dafuer, dass ein\r
aufgeblaehter Feed noch dicker wird und die Formatierungen sind einfach\r
eine Frechheit. Wenn jemand meint, dass er etwas in roter Farbe markieren\r
muss, darf er das gerne fuer sich machen. Aber wenn er es in einem Feed\r
macht, ist er ziemlich undankbar seinen Lesern gegenueber. Was ist, wenn der\r
Newsreader des Lesers einen roten Hintergrund hat? Oder der Leser\r
farbenblind ist?\r
\r
Nachtrag: Man muss nicht jedem Autor boese Absichten unterstellen, es kann\r
sich durchaus manchmal nicht um Missbrauch sondern falschen Gebrauch\r
handeln, beispielsweise durch die Blogsoftware verursacht. Je mehr Feeds\r
ich persoenlich lese, desto mehr faellt mir ein Punkt besonders auf: Feeds\r
verlangen mesit einen eindeutigen Identifier fuer jeden Beitrag, womit\r
sich doppelte Beitraege vermeiden liesen. Leider fuehren viele Leute (oder\r
deren Software) das Prinzip ad absurdum: Sie finden einen Beitrag, den\r
sie auf ihrem eigenem Blog anderen empfehlen wollen, doch anstatt direkt\r
auf das Original zu linken, die Original-ID zu uebernehmen und nur eine\r
kurze Beschreibung dazu zu veroeffentlichen, erstellen sie einen eigenen\r
Beitrag mit eigener ID und verlinken diesen. Der User bekommt dann unter\r
Umstaenden nur zu lesen, dass der Autor einen Beitrag gefunden, den er\r
toll findet und der unter einem anderen Link erreichbar ist. Positives\r
Beispiel war lange Zeit Fefe [9], der konsequent auf den Originalbeitrag\r
gelinkt hat. Leider ist er inzwischen umgefallen und linkt auch auf sich\r
selber... auf Bitten seiner User! Negativ Beispiel, das der Ausloeser\r
fuer diesen Nachtrag war, ist FixMBR [10]: Ich finde es zwar auch schoen,\r
dass ihr bei Miwi [11] mitlest und euch ueber jede Folge von Chaosradio [12]\r
oder Pofacs [13] freut, aber ich habe sie selbst im Feedreader. Also bitte,\r
linkt in Zukunft aufs Original, nutzt die Original-ID und schreibt euren\r
Kommentar einfach in die Beschreibung rein; zumindest wenn ihr keine neuen,\r
eigenen Gedanken reinbringt, denn fuer diesen Fall gibt es ja den SOURCE-\r
Tag und VIA-Links.      \r
\r
Als letzter Kritikpunkt bleibt das Polling. In der heutigen Zeit ist es\r
unverstaendlich, warum ein geneigter Leser alle paar Minuten selbst\r
nachschlagen muss, ob es Neuigkeiten gibt. Es waere viel besser, wenn mir\r
der Autor selbst bescheid gibt, wenn ein neuer Eintrag vorhanden ist. Das\r
Problem verstaerkt sich, wenn der Feed-Autor die vorangegangenen Pukte nicht\r
beachtet hat: Wer beispielsweise seine kompletten Artikel samt\r
ausschweifender HTML-Fortmatierung in den Feed packt, darf sich nicht ueber\r
den Traffic wundern, den es erzeugt, wenn jeder Leser stuendlich oder\r
zumindest mehrmals taeglich sich den Feed herunterlaedt.\r
\r
Der Nutzen\r
~~~~~~~~~~\r
\r
Inzwischen muss ich aber durchaus den Nutzen, den Feeds mit sich bringen\r
anerkennen, ja ich muss sogar sagen, dass Feeds mir einige Arbeit abnehmen.\r
Ich muss nicht mehr jedesmal eine bestimmte Webseite ansurfen um mich zu\r
informierenn, sondern kann einfach ihren Feed speichern und bin bedient.\r
\r
Im Gegensatz zu meiner frueheren Position kann ich mittlerweile durchaus\r
nachvollziehen, warum man einen kompletten Artikel in einen Feed packt. Es\r
ist sehr angenehm sich morgens alle aktualisierten Feeds herunterzuladen\r
und sich dann im Laufe des Tages unterwegs die ganzen Artikel durchlesen\r
zu koennen. Natuerlich blaeht das ganze natuerlich die Feeds unheimlich auf,\r
weshalb es besser ist, den Feed nur als Index zu nutzen und sich bei\r
Bedarf einfach zusaetzlich alle Artikel mit herunterzuladen. Das ist eine\r
Aufgabe, die auch gern der Feedreader automatisch erledigen kann, er weiss\r
ja auch, auf was die Links zeigen. Hier waere es dann natuerlich schoen,\r
wenn man gleich eine Druckversion verlinken wuerde, aber da die meisten\r
Feedautoren Leute auf ihre Seite holen wollen, wird das wohl\r
Wunschdenken bleiben. Trotzdem hege ich inzwischen die Hoffnung, dass\r
Feeds das Internet ein wenig aus der Gewalt der grafikgeilen Klick-User\r
befreit und man sich wieder verstaerkt dem wichtigen Inhalten zu wendet;\r
zumindest wenn die ganzen Seonauten und Co. nicht die tollen HTML-\r
Moeglichkeiten in Feeds missbrauchen.\r
\r
Nunja, ein weiterer, viel wichtigerer Punkt ist aber noch die\r
Maschinenlesbarkeit. Man kann sich nun ganz einfach eine Seite\r
-beispielsweise unter soup.io [14]- oder einen eigenen Feed einrichten,\r
die/der ganz gezielt die fuer einen wichtigen Meldungen zusammenfasst oder\r
die Meldungen noch entsprechend der eigenen Wuensche aufarbeitet.\r
\r
Die Alternativen\r
~~~~~~~~~~~~~~~~\r
\r
Waehrend ich in meinem letzten Beitrag viele Pseudoalternativen nannte,\r
muss ich heute wohl eingestehen, dass ich etwas vorbelastet war und die\r
wenigsten davon wirklich brauchbar waren. Directory-Listings oder\r
aufgeraeumte Index-Dateien sind nur bedinkt als Feed brauchbar. Man\r
koennte beispielsweise die Feeds auch als "normale" Textdateien hinterlegen\r
mit einem Link pro Zeile, doch damit waere nur das XML-Manko weg. Das kann\r
keine Loesung sein, denn so sehr ich XML fuer allzu oft eingesetzt halte, hier\r
ist es gut und richtig, weil die Metainformationen die man dadurch erhaelt\r
sowie die Maschinenlesbarkeit den Nachteil der Dateigroesse wieder wett machen.\r
\r
Auch das Einbetten von Feedinformationen in die Indexdatei kann unter\r
Umstaenden funktionieren, ist aber auch nur das gleiche Konzept in\r
unterschiedlicher Auspraegung, meiner Meinung in einer schlechteren. Ein\r
besserer Ansatz waere es die Indexdatein gleich durch den Feed zu ersetzen\r
und die Artikel nur noch lose ohne das Korsett einer Webseite zu\r
veroeffentlichen.\r
\r
Nachtrag: Inzwischen habe ich das selbst ausprobiert und kann bestaetigen,\r
dass das wirklich gut funktioniert. Ich nutze einen Atom-Feed als\r
Ausgangsmaterial, dessen integrierter XSL-Style dafuer sorgt, dass Leute die\r
sich den Feed in einem Browser anschauen, eine vollfunktionsfaehige XHTML-\r
Seite angezeigt bekommen. Zum Stylen dieser Seite nutze ich weiterhin CSS,\r
denn XSL-FO ist deutlich zu viel des Guten fuer diesen Zweck. Reines\r
Formatieren des Feeds per CSS geht zwar auch, hat aber den Nachteil, dass\r
in den meisten Browsern die Link-Elementer nicht mehr gesondert angezeigt\r
werden, wie es frueher ueblich war, sondern nur intern verarbeitet werden.\r
Im Klartext heisst das, dass es zwar gut aussieht, aber die Links zu den\r
einzelnen Artikeln nicht nutzbar sind. Zweiter Nachteil: Nicht jeder\r
Browser, insbesondere die von mir so geliebten Textversionen, kann mit XML\r
so problemlos umgehen. Allerdings kann man ja zusaetzlich eine Indexdatei\r
aus dem gleichen Stylesheet erstellen lassen oder einfach direkt auf einen\r
Feedreader verweisen.\r
\r
Die einzige wirkliche Alternative die ich momentan sind eigentlich die\r
"Vorgaenger" der Feeds, die Newsletter oder gar Usenet-Beitraege. Positiv\r
hierbei ist, dass die Meldungen nur einmal an die Empfaenger gesendet werden\r
und man nicht alle paar Stunden den Feed pollen muss, um auf dem aktuellen\r
Stand zu blieben. Leider werden die meisten Newsbletter nur einmal am Tag\r
verschickt und bieten nur eine Kurzversion der Artikel an. Wuerde man das\r
Konzeptrichtig nutzen, wuerde man fuer jede Meldung eine Mail verschicken,\r
die dann auch gleich den kompletten Text beinhaltet. Leider ist das aus\r
oben genannten Gruenden eher Wunschdenken.\r
\r
Nachtrag: So richtig zieht das Argument eigentlich nicht. Ob man nun einen\r
Newsserver des Usenets nach Updates fragt, einen Feed direkt von der Autoren\r
Website pollt oder seine Mails per POP vom Mailserver holt ist eigentlich\r
relativ egal. Das Usenet hat den Vorteil, dass die Server einen globalen\r
Index haben (zumindest von den Newsgruppen, die sie anbieten) und man sich\r
also sich nicht erst muehsam seine Feeds aus Blogs herausziehen muss.\r
Aehnliche Funktionalitaet bieten inzwischen so genannte Planeten, also\r
Sammelstellen die verschiedene Feeds zu einem Thema in einem einzigen\r
Feed buendeln. Mailinglisten wuerden das Polling nur dann etwas\r
relativieren, wenn man seine Mails beispielsweise per IMAP direkt auf dem\r
Server liest, aber im Grunde muss die Informationen ja so oder so zum\r
geneigten Leser, es ist also egal. Trotzdem haben Mailinglisten und auch\r
das Usenet den Vorteil, dass man einem Thema direkt folgen kann und\r
Kommentare und Folgeartikel von der selben zentralen Stelle bekommt; sie\r
also nicht erst in anderen Blogs aufrufen muss.\r
\r
Ob eine der Alternativen funktioniert oder sinnvoll ist, haette man -und\r
hat man sicher- ausprobieren muessen, aber nun haben wir Feeds und einen\r
Standard, nun sollten wir auch dabei bleiben.\r
\r
Die Werkzeuge\r
~~~~~~~~~~~~~\r
\r
Nun, es macht keinen Sinn sich lang ueber Webfeeds aufzuregen. Es gibt sie\r
in ihrer derzeitigen Form nunmal, sie haben Vorteile, aber auch Nachteile\r
und irgendwie muss man damit klar kommen. Gottseidank gibt es eine gerade\r
unueberschaubare Anzahl von kleinen Hilfsprogrammen, die einen das Arbeiten\r
mit Webfeeds tatsaechlich erleichtern. Da ich haeufig remote ueber SSH auf\r
einem Rechner arbeite, habe ich eine gewisse Affinitaet fuer\r
Befehlszeilenprogramme. Als Feedreader habe ich daher lange das Programm\r
Newsbeuter [15] eingesetzt, welches allerlei Funktionen bietet und im\r
Gegensatz zu den meisten CLI-Feedreadern noch sehr aktiv weiterentwickelt\r
wird.\r
\r
Nachtrag: Ich nutze derzeit wieder Newsbeuter und moechte hier noch kurz\r
einen kleinen Filter-Trick [16] dazu vorstellen, den ich mir von Andreas\r
Krennmair [17], dem Entwickler von Newsbeuter abgeschaut habe. Um einen\r
Metafeed zu erzeugen, der alle ungelesenen Eintraege auflistet, muss man\r
folgendes in seine URL-Liste eintragen (die Anfuehrungszeichen gehoeren\r
genau so, wie sie hier stehen!): "query:Unread Articles:unread = \"yes\""\r
\r
Inzwischen bin ich aber auf das kleine Tool rss2email [18] umgestiegen, dass\r
quasi ein Konverter ist. Es liest verschiedene Feeds ein und schickt fuer\r
jeden Eintrag eine eMail an den jeweiligen Nutzer. Das ganze funktioniert\r
natuerlich sowohl mit lokalen als auch mit im Internet stehenden\r
Mailservern. Weitere Anpassungen lassen sich leicht selbst vornehmen, da\r
es eigentlich nur eine Sammlung von Python-Scripts ist. Allerdings eignet\r
sich das ganze nur fuer Leute, die nur wenige Feeds nutzen, da es sonst zu\r
unuebersichtlich in der Mailbox wird. Dieses Problem kann man natuerlich mit\r
Mailfiltern wie procmail [19] umgehen. Alternativ kann sich der IMAP-Nutzer\r
ueber rss2imap [20]freuen. Dieser Namensvetter stellt die Mails gleich in den\r
richtigen IMAP-Ordner ein. Beide Programme arbeiten trotz des Namens\r
natuerlich auch problemlos mit Atomfeeds.\r
\r
Wer Feeds direkt im Firefox Browser lesen will, dem kann ich nur Brief [21]\r
ans Herz legen. Es nutzt die Feeds die als "Dynamische Lesenszeichen"\r
gepseichert wurden. Man kann sowohl einzelne Feeds anschauen, als auch einen\r
Metafeed aus allen ungelesenen Eintraegen erzeugen und diesen nutzen. Brief\r
funktioniert uebrigens auch sehr gut mit Vimperator zusmamen, denn es zeigt\r
ein Icon in der Statusleiste an.\r
\r
Zum Schluss moechte ich euch noch rsstool [22] vorstellen, mit dem es moeglich\r
ist verschiedene Feeds (RSS und ATOM) zu parsen, zu verarbeiten und geaendert\r
wieder auszugeben. Ich habe es kurzzeitig dazu verwendet mir aus allen\r
abonnierten Feeds einen einzigen zu generieren, der dann leichter zu\r
handhaben war. Doch kann man mit dem Tool einiges mehr machen, am besten\r
einmal ausprobieren!\r
\r
Nachtrag: Als XML-Prozessor verwende ich meist xmlstarlet [22], xmlproc [23],\r
xsltproc [24] oder direkt die libxslt- [25], librss- [27] und libxml- [26]\r
Bibliotheken.  Wer seine Feeds in einen Master-Feed zusammenfuehren will,\r
der kann dazu den Universal Feed Parser [28] von Mark Pilgrim [29] nehmen;\r
darauf aufbauend ist auch der Planet Feed Reader [30] sehr zu empfehlen, den\r
man entweder als eigenen Feedreader oder als oeffentliche Feed-Sammlung\r
nutzen kann. Aehnliches laesst sich mit Gregarius [31] bewerkstelligen.\r
Nicht ganz passend zum Thema XML, aber trotzdem hier aufgefuehrt fuer den\r
Fall, dass jemand XML/XHTML/HTML in ein "besseres" Format konvertieren\r
will: html2latex [32]\r
\r
\r
Reinventing the wheel - Auf der Suche nach dem Zen des Bloggens\r
---------------------------------------------------------------\r
\r
Vor einiger Zeit hat mich Tim [33] ueber den neusten Trend in Sachen Web2.0-\r
Bubble-Blogging aufgeklaert. Da die Kommentare ja nur noch laestig sind und\r
das mit dem Spam ja so viel Arbeit ist, gibt es die Moeglichkeit, die\r
Kommentare extern zufuehren. Bei meinem Rant gegen so einen Unsinn, ist mir\r
mal wieder bewusst geworden, dass die ganzen als neu beworbenen Eigenschaften\r
und Moeglichkeiten des Web (bzw. des Web2.0) alle bereits schon laengst\r
erfunden worden sind, hier der Originalbeitrag:\r
\r
> Kacke, jetzt hats mir gerade nen elendlangen text verhauen. Deshalb hier die\r
> Kurzfassung: Erstmal danke dafuer, dass du mich auf den neuen "Trend"\r
> aufmerksam gemacht hast. Ist an mir vorbei gerauscht. Ich hab daher noch\r
> keine differenzierte Meinung dazu, aber en paar Sachen kann ich mir nicht\r
> verkneifen. Zuvor aber noch kurz zu meinem Standpunkt bei Kommentaren: Jeder\r
> darf und soll sich Gedanken zu meinen Veroeffentlichungen machen. Diese darf\r
> er dann gerne mir per Mail zu schicken. Wenn er will veroeffentliche ich das\r
> dann sogar (teilweise automatisiert..). Wenn ihm das nicht ausreicht, kein\r
> Problem, soll er nen Gegenpost schreiben und auf seinem Blog, Website oder\r
> wo auch immer veroeffentlichen..\r
>\r
> Ok, jetzt aber mal zum Thema. Grundsaetzlich steh ich den meisten\r
> Zentralisierungen eher skeptisch gegenueber, insbesondere dann, wenn die\r
> Zentralisierung nicht inhouse erfolgt, sondern an einen Dritten uebergeben\r
> wird. So auch hier. Gehen wir doch mal die Vorteile, die die verlinkten\r
> Blogs nennen kurz durch:\r
>\r
> > Ich mag mich nicht mehr mit Spam und Akismet rumquaelen. Ich habe keine\r
> > Zeit mehr, mich durch Akismet auf der Suche nach versehentlich Markiertem\r
> > zu machen.\r
>\r
> Das Argument Faulheit ist zwar sehr beliebt, aber nicht immer das beste. Es\r
> ist ja schoen, dass er erkannt hat, dass er das mit den Kommentaren nicht\r
> machen will/kann und daher das an jemanden auslagern will, der es kann. Ob\r
> man es mit den Daten der User erkaufen muss, is so ne Sache..\r
>\r
> > disqus kann threaded Kommentarstraenge und noch ein Dutzend Funktionen\r
> > mehr. Das Widget rechts in der Sidebar find ich auch ganz schick. Alles\r
> > ohne sich mit einem halben Dutzend an WP-Plugins abzumuehen.\r
>\r
> Threaded View? Wow, das is ja was gaaaanz neues. Hatten wir im Usenet, in\r
> der BBS-Szene und in Mailinglisten schon ne halbe Ewigkeit. Auch neuere\r
> Forensoftware und Co. koennen sowas schon. Das zweite Argument ist wieder\r
> Faultheit, dazu s.o..\r
>\r
> > Sehr, sehr grossartig: Kommentare direkt per Email beantworten.\r
> > Antwortmail eines Kommentars direkt an disqus, und der Kommentar wird\r
> > automatisch gepostet. Zeitsparen deluxe.\r
>\r
> Haha, guter Witz. Als ich damals, als Blogs aufkamen mit meiner antiquierten\r
> eMail ankam, wurde ich ausgelacht. Und jetzt ist es wieder hipp?\r
>\r
> > Mit der Moeglichkeit zu Voten etc. bieten sich kuenftig viele Moeglichkeiten,\r
> > Kommentare einzusetzen; da wird noch einiges kommen\r
>\r
> Votes sind ja auch was ganz neues.. Haben inzwischen ja auch schon viele\r
> integriert.\r
>\r
> > Trackbacks mittlerweile (wenn auch noch unschoen integriert) und\r
> > Videokommentare (wenn mir auch der Nutzen noch unklar ist) gibt es auch\r
> > und hab ich auch alles aktiviert\r
>\r
> Wo is da der Vorteil?\r
>\r
> > friendfeed-Integration\r
>\r
> WTF? Kann ich nix zu sagen, hab ich nicht, kenn ich nicht, mag ich nicht :).\r
>\r
> Ok, dann gab es auf nem anderen Blog noch folgenden Vorteil:\r
>\r
> > einmal anmelden, auf x Blogs kommentieren\r
>\r
> Single-Sign-On ist ja gross im Kommen, aber warum man das zentral machen muss\r
> is mir ne Frage. Logisch, dass wenn jeder die KOmmentare bei dem Dienst hat,\r
> man nur ein Login braucht. Bald wid aber nen zweiter und nen dritter und und\r
> und ... Dienst erscheinen, der die erfolgreiche Copycat macht und viel\r
> hipper ist, als der hier genannte. Und schon verteilen sich die Kommentare\r
> auf zwei, drei, vier, n Dienste. Das ist kein Vorteil!\r
>\r
> So, dann fassen wir mal zusammen. Im Grunde genommen ist das Argument, dass\r
> fuer den Dienst spricht genau eins: Faulheit. Alle "Features" wurden schon\r
> vor Ewigkeiten erdacht und ausgearbeitet und scheinen erst seit kurzem den\r
> Weg in die Blogosphaere zu finden. Alle Features lassen sich wohl auch mit\r
> vielen Plugins fuer WP nachruesten, doch hier hat man eine zentrale\r
> One-Click-Loesung, die einem die ganze Arbeit abnimmt. Natuerlich haette man\r
> das ganze auch in ein UBER-Plugin packen koennen, aber damit laesst sich ja\r
> schlecht Geld verdienen. Wo kaemen wir da hin, wenn der Benutzer am Ende\r
> selbst die Kontrolle ueber seinen Content haette!!\r
\r
Ich moechte die ganzen Punkte jetzt nicht nochmals aufrollen (wer daran\r
Interesse hat, darf mich aber gerne per Mail anschreiben), denn der wichtige\r
Punkt ist nur, dass sich das alles wiederholt. Und so musste ich jetzt auch\r
bei meinem Arbeiten am Blog feststellen, dass ich das irgendwie alles schonmal\r
getan habe. Ausloeser dieses Mal war, dass ich meine bisherige Struktur aus\r
einer XML-Datei im Atom-Format [34] fuer den Blog und weiteren XML-Files im\r
XHTML-Format fuer die einzelnen Eintraege durch eine Atom-Only-Loesung\r
ersetzten will. Atom bietet die Moeglichkeit, einzelne Entries auch in eine\r
eigene alleinstehende Datei zu packen. Zudem ist es moeglich, den kompletten\r
Inhalt entweder im XHTML-Format oder als Klartext ueber das Content-Element\r
direkt in die Entry-Elemente zu packen. Im Endeffekt ist so ein Entry nichts\r
anderes, als ein XHTML-Dokument, dass mit einigen Metadaten angereichert\r
worden ist. Diese Daten sind zwar bei Atom standardisiert, aber auch in HTML\r
lassen sie sich standardisiert abbilden, beispielsweise ueber DublinCore [35].\r
\r
Ich bin daher zu der Meinung gelangt, dass es immer wieder neue Standards\r
geben wird, denen es aehnlich Modetrends in der echten Welt gilt\r
hinterherzuhecheln, obwohl es alles eigentlich "dasselbe in Gruen" ist. Der\r
aktuelle Gral aus meiner Sicht ist eben so eine Atom-Only-Loesung, die XSLT\r
dazu nutzt, um auch im Webbrowser gut auszusehen und die das Publishing ueber\r
die etwas in Vergessenheit geratenen HTTP-Verben bzw. Methoden (get, put,\r
post, head, delete, trace, options, connect) erledigt, so wie es das Atom\r
Publishing Protocol [36] vorsieht. Ich bin momentan mit meinen Skripten\r
relativ nah daran, diese "reine Lehre" umzusetzen, aber die Frage ist, was\r
kommt danach? Atom ist momentan der beste Kompromiss, aber es fehlt an allen\r
Ecken und Enden. Es wird daher sicherlich einen Nachfolger geben, der\r
eigentlich wiederum nur das bekannt anders ausdrueckt. Und trotzdem wird sich\r
die Meute auf ihn stuerzen und alles was diesem Standard nicht folgt als\r
uncool verdammen. Nun, wie soll ich es sagen: Ich bin uncool. Ich werde das\r
einfach -aehnlich meiner realen Einstellung- nicht laenger mitmachen.\r
\r
Bitte versteht das nicht falsch, Standards im Allgemeinen und Webstandards im\r
Speziellen sind eine klasse Sache, aber man muss echt nicht tausend Standards\r
rausbringen, die eigentlich nur den selben Inhalt anders beschreiben. Ich\r
selbst habe mich noch nicht entschieden, wie genau ich vor gehen werde. Zum\r
einen koennte ich die Atom-Sache weiter verfolgen und sobald sie mal laeuft,\r
einfach auf nachfolgende Standards scheissen, sofern sie keinen Vorteil\r
bringen. Alternativ koennte ich auch einen fingerd, einen Newsserver oder eine\r
Mailingliste aufsetzen um meine Pseudoweisheiten und Rants unter das geneigte\r
Zuhoerervolk zu bringen. Bei den letzten Moeglichkeiten wuerde ich deutlich\r
weniger "bloggen" als bisher, denn ich bin zudem zu der Ueberzeugung gelangt,\r
dass es eigentlich ziemlich bescheuert ist die ganze Zeit irgendwelche\r
Meldungen in eigenen Worten zu kommentieren,wenn ich sowieso mit dem Original-\r
poster uebereinstimme. Es waere eigentlich anstaendiger, einfach regelmaessig\r
meine Feedliste zu veroeffentlichen, dann kann jeder sehen, was ich lese und\r
sich seine eigenen Gedanken dazu machen. Veroeffentlichen wuerde ich dann nur\r
noch eigene Artikel, persoenliche Sachen (ha, ein Novum) und Links die ich\r
nicht per Feed aufgeschnappt habe. Gut, ab und an werde ich es nicht lassen\r
koennen, auch einen Eintrag aus einem bekannten Feed zu zerlegen, aber\r
definitiv nicht so haeufig, wie es momentan der Fall ist. Ganz neben bei sei\r
auch noch erwaehnt, dass das meiste was so getrascht -aeh..gebloggt- wird\r
nicht wirklich laengerfristig von Interesse ist. Warum sind die meisten\r
Bloggs eigentlich mehr zeitlich, als inhaltlich gegliedert? Kann mir das mal\r
jemand erklaeren? Hallo? Echo? Dass ich mit der Meinung nicht allein bin,\r
zeigt folgender Kommentar zu einem Artikel auf PeterKroener.de [37]:\r
\r
> Und wie wahrscheinlich ist es, dass es den Besucher wirklich interessiert,\r
> was der Blogger vor 14 Tage zuvor verzapft hat, geschweige denn Monate oder\r
> gar Jahre zuvor?\r
\r
Aber, aber, aber... dann gibt es ja gar keinen Feed mehr! Ja, richtig. Je nach\r
System haue ich Updates (wenn gewuenscht) per Mail oder eben das jeweilige\r
Medium raus. Dann habt ihr auch gleich eure Kommentarfunktion, einfach nur den\r
Reply-Button in eurem MUA druecken und ab geht's. Das das ganze dann nicht\r
mehr besonders webzwonullig ist, ist mir zwar bewusst, aber eigentlich auch\r
egal. Um es mit den Worten von Yamagi [38][39] auszudruecken:\r
\r
> Von Blogs und Plans\r
> --15.10.2007--\r
> Mir wurde eben gesagt ich sei ein Z-Blogger und wuerde nur des\r
> Bloggensbloggen. Ausserdem wuerde ich nicht den von Robert Basic gelegten\r
> Massstaeben folgen und mich nicht an Bloggersville beteiligen. Liebe Leute,\r
> wisst ihr, was ein Planfile und was finger(1) ist? Offensichtlich nicht.\r
> Also: Weblog != finger. Ach nee, ihr habt jawas mit BASIC zu tun, einer 1964\r
> entwickelten Programmiersprache,also vielleicht besser "Weblog neq finger".\r
> OK, fuer euch nicht Infos mal ein wenig ausfuerlicher: Ganz frueherhatte man\r
> grosse, geekige Unixkisten. Hier konnte man seine Erlebnisse, Vorhaben und\r
> Taetigkeiten in einer datei namens .plan in seinem Heimat-verzeichnis\r
> hinterlegen. Andere Nutzer konnten diese dann mit dem Befehl "finger\r
> nutzername" abfragen. Als die ersten Netzwerke aufkamengoss man diesen\r
> Befehl in ein Netzwerkprotokoll. Das war dann fingeraus dem schoenen Jahr\r
> 1977. Dies ist RFC 742 definiert.\r
>   http://tools.ietf.org/html/rfc742\r
> Spaeter als die Netze komplexer wurden, war ein neues Protokollnoetig. Dies\r
> ist das aktuelle finger aus dem Jahr 1991, definiertin RFC 1288.\r
>   http://tools.ietf.org/html/rfc1288\r
> Haettet ihr einen finger-Client auf eurem Rechner, koenntet ihrja einmal\r
> "finger yamagi@finger.yamagi.org" eingeben. Eventuellauch mit der Option -T.\r
> Was lernen wir daraus? Haltet einfach mal die FRESSE, wenn ihr nicht wisst,\r
> worum es geht und mischt euch nicht in Dinge ein die aelter als ihr sind und\r
> ihr gar nicht versteht.\r
\r
Etwas harsch formuliert, aber im Grunde trifft es doch den Kern. Ich lebe\r
nicht in Bloggersville oder Klein Bloggersdorf und ich habe mich auch nicht\r
mit irgendlwechen Web2.0-Drogen vollgepumpt um in die Bloggosphere zu\r
entschweben. Und ganz neben bei, so "social" oder gar "sozial" (man beachte\r
das beide Worte im Deutschen leicht andere Konnotation besitzen..) wie die\r
Web2.0-Gesellschaft immer tut, sind sie mit ihren Blogs und SocialNetworks und\r
SuperHuperDuper-Webdiensten gar nicht. Mailinglisten und die Usenethierarchien\r
sind da deutlich sozialer. Welcher Web2.0-Dienst unterstuetz denn heute noch\r
das Kommentieren ohne Anmeldung, einfach so, per eMail? Soviele sind das\r
nicht, also fuck you!\r
\r
Ich verbleibe mit freundlichen Gruessen an die Leute, die meinen IRL- und IOL-\r
Lebensraum verschmutzen, und einem Zitat zum Schluss:\r
\r
Peter Kroener:\r
> Eine Website ist dann gut, wenn nichts mehr da ist, das man loeschen kann.\r
\r
\r
[1] http://tools.ietf.org/html/rfc4287\r
[2] http://diveintomark.org/archives/2004/05/27/howto-atom-linkblog\r
[3] http://diveintomark.org/archives/2004/02/04/incompatible-rss\r
[4] http://en.wikipedia.org/wiki/Atom_(standard)\r
[5] http://de.wikipedia.org/wiki/Atom_(Format)\r
[6] http://de.wikipedia.org/wiki/Resource_Description_Framework\r
[7] http://en.wikipedia.org/wiki/RSS\r
[8] http://de.wikipedia.org/wiki/RSS\r
[9] http://blog.fefe.de/\r
[10] http://www.fixmbr.de/\r
[11] http://miwi.bsdcrew.de/\r
[12] http://chaosradio.ccc.de/\r
[13] http://www.pofcas.de/\r
[14] http://www.soup.io/\r
[15] http://www.newsbeuter.org/\r
[16] http://synflood.at/blog/index.php?/archives/698-Meta-Feeds-fuer-newsbeuter.html\r
[17] http://synflood.at/\r
[18] http://rss2email.infogami.com/\r
[19] http://www.procmail.org/\r
[20] http://rss2imap.sourceforge.net/\r
[21] https://addons.mozilla.org/de/firefox/addon/4578\r
[22] http://xmlstar.sourceforge.net/\r
[23] http://xmlsoft.org/\r
[24] http://xmlsoft.org/XSLT/\r
[25] http://xmlsoft.org/XSLT/\r
[26] http://xmlsoft.org/\r
[27] http://api.kde.org/3.5-api/kdepim-apidocs/akregator/src/librss/html/index.html\r
[28] http://www.feedparser.org/\r
[29] http://diveintomark.org/\r
[30] http://www.planetplanet.org/\r
[31] http://gregarius.net/\r
[32] http://html2latex.sourceforge.net/\r
[33] http://timsahling.de/blog/2008-06-20/auslagerung-der-kommentare-an-fremden-webdienst/\r
[34] http://tools.ietf.org/html/rfc4287\r
[35] http://dublincore.org/\r
[36] http://tools.ietf.org/html/rfc5023\r
[37] http://www.peterkroener.de/blog-permalinks-mit-datum-oder-kategorie-sind-doof/\r
[38] http://www.yamagi.org\r
[39] http://finger.yamagi.org/!b12