Donnerstag, 12. Februar 2004
s9y: Individualisierter RSS-Feed per Conditional Get
Seit gerade unterstützt die hier verwendete Serendipity-Blogsoftware im RSS-Feed das "Conditional Get".
Hört sich technisch an, ist aber wundervoll Nutzerfreundlich.
Um ganz am Anfang anzufangen: RSS ist ein XML-inspiriertes Format zum Austausch von Nachrichten. Heutzutage wird es benutzt, um über neue Inhalte informiert zu werden. Alle Blogs die ich lese grase ich nicht mühsam Webseite für Webseite ab, sondern nutze dafür einen RSS-Reader, der eben diese Dateien der Blogs ausliest und mir wie in einem E-Mail Client übersichtlich darstellt. Genauer, hübscher und nachvollziehbarer erklärt Alp Uckan dies in seinem Artikel Was ist RSS.
Fahren wir fort: RSS hat unter anderem den Nachteil, das normalerweise ein solcher Feed immer 15 Einträge enthält. Wenn ich den Feed jetzt und in 5 Minuten abrufe, erhalte ich also beide Male diese 15 Einträge. Ganz egal, dass ich die 15 ja schon habe. Dadurch verschwende ich Bandbreite auf Server- und Clientseite. Ausserdem wirft es das Problem auf, dass wenn ich 2 Wochen in Urlaub war und es seitdem 17 neue Artikel gab, ich ja nur die 15 aktuellsten erhalte. Dadurch entsteht bei der RSS-Benutzung gewissermaßen der Zwang immer am Ball zu bleiben.
Dem schafft ein Caching-Mechanismus abhilfe. Der Client übermittelt dabei dem Server, wann er das letzte Mal einen Artikel gesehen hat. Wenn es seitdem nichts neues war, wird nichts übertragen. Wenn es seitdem 42 neue Artikel gab, kriege ich 42 neue Artikel. Praktisch, was?
Hört sich technisch an, ist aber wundervoll Nutzerfreundlich.
Um ganz am Anfang anzufangen: RSS ist ein XML-inspiriertes Format zum Austausch von Nachrichten. Heutzutage wird es benutzt, um über neue Inhalte informiert zu werden. Alle Blogs die ich lese grase ich nicht mühsam Webseite für Webseite ab, sondern nutze dafür einen RSS-Reader, der eben diese Dateien der Blogs ausliest und mir wie in einem E-Mail Client übersichtlich darstellt. Genauer, hübscher und nachvollziehbarer erklärt Alp Uckan dies in seinem Artikel Was ist RSS.
Fahren wir fort: RSS hat unter anderem den Nachteil, das normalerweise ein solcher Feed immer 15 Einträge enthält. Wenn ich den Feed jetzt und in 5 Minuten abrufe, erhalte ich also beide Male diese 15 Einträge. Ganz egal, dass ich die 15 ja schon habe. Dadurch verschwende ich Bandbreite auf Server- und Clientseite. Ausserdem wirft es das Problem auf, dass wenn ich 2 Wochen in Urlaub war und es seitdem 17 neue Artikel gab, ich ja nur die 15 aktuellsten erhalte. Dadurch entsteht bei der RSS-Benutzung gewissermaßen der Zwang immer am Ball zu bleiben.
Dem schafft ein Caching-Mechanismus abhilfe. Der Client übermittelt dabei dem Server, wann er das letzte Mal einen Artikel gesehen hat. Wenn es seitdem nichts neues war, wird nichts übertragen. Wenn es seitdem 42 neue Artikel gab, kriege ich 42 neue Artikel. Praktisch, was?
Herausgefunden habe ich das dank Thiemo Mättig (hätte man mir ja ruhig früher mal unter die Nase schieben können...), und leider hat es für die serendipity-Implementation etwas Umstrukturierung gefordert.
Unter anderem gab es vorher kein Datenfeld, dass mich über die letzte Aktualisierung eines Artikels in s9y informiert hat. Wäre also ein Artikel rückdatiert veröffentlich worden (wie das gewisse Herren mehr als überstrapazieren), dann würde mir als RSS-Leser diese Veröffentlichung entgehen.
So wird nun der Feed aber anhand das "zuletzt aktualisiert"-Datenfeldes sortiert, und man verpasst nun auch keine Aktualisierung eines 2-Jahre alten Eintrages mehr. Hübsch, was?
Die Implementation stelle ich vorerst noch nicht ins CVS von s9y, um die Effekte auf meiner Seite etwas zu testen. Die IF_MODIFIED_SINCE Header (vom Client) und das Datum des letzten Eintrages (Server) werden beide in die GMT-Zeitzone konvertiert um einen Vergleich zu ermöglichen.
Gibt es unerwünschte Nebeneffekte, die ich nicht bedacht habe? Könnten Dienste wie bloglines.com, feedster.com oder ähnliches Probleme mit sich ziehen?
Über Tests meines Feeds würde ich mich freuen. Wagemutige können gerne den s9y Patch gegen das CVS vom 11.02.2004 ausprobieren (mit Debugging-Code).
Unter anderem gab es vorher kein Datenfeld, dass mich über die letzte Aktualisierung eines Artikels in s9y informiert hat. Wäre also ein Artikel rückdatiert veröffentlich worden (wie das gewisse Herren mehr als überstrapazieren), dann würde mir als RSS-Leser diese Veröffentlichung entgehen.
So wird nun der Feed aber anhand das "zuletzt aktualisiert"-Datenfeldes sortiert, und man verpasst nun auch keine Aktualisierung eines 2-Jahre alten Eintrages mehr. Hübsch, was?
Die Implementation stelle ich vorerst noch nicht ins CVS von s9y, um die Effekte auf meiner Seite etwas zu testen. Die IF_MODIFIED_SINCE Header (vom Client) und das Datum des letzten Eintrages (Server) werden beide in die GMT-Zeitzone konvertiert um einen Vergleich zu ermöglichen.
Gibt es unerwünschte Nebeneffekte, die ich nicht bedacht habe? Könnten Dienste wie bloglines.com, feedster.com oder ähnliches Probleme mit sich ziehen?
Über Tests meines Feeds würde ich mich freuen. Wagemutige können gerne den s9y Patch gegen das CVS vom 11.02.2004 ausprobieren (mit Debugging-Code).
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
RSS ist _ein_ Format zum Austausch von Nachrichten? Ich hatte bisher den Eindruck, daß RSS viele Formate ist, alle subtil inkompatibel, und außerdem umgeben von einem Haufen weiterer Formate, die dasselbe tun. Außerdem alle irgendwie kaputt implementiert, sodaß ein RSS Reader mit einem Haufen defekten und nicht validierendem Müll umgehen muß, damit er überhaupt was Sinnvolles zu lesen bekommt.
Hat jemand in irgendeinem Blog auf dieser Welt mal diskutiert, was der Vorteil von diesem Keks gegenüber SMTP und NNTP ist?
Mein ja nur,
Kristian
Hat jemand in irgendeinem Blog auf dieser Welt mal diskutiert, was der Vorteil von diesem Keks gegenüber SMTP und NNTP ist?
Mein ja nur,
Kristian
Mir geht das Verständnis für dieses Feature ab, mal abgesehen davon, das Kristian nicht ganz unrecht hat.
1. Sollte das Wiederholte anfordern/empfangem über HTTP verhindert werden.
2. Kann man seinen RSS auch automatisch generieren und so per URL-Parameter die Anzahl der Items bzw. das Startdatum bestimmen.
3. Ist das wahrlich nur für Desktopreader interessant, und weil eRONA webbasiert ist, interessiert es mich nicht Das gilt natürlich genauso für alle anderen webbasierten Aggregatoren.
just my 2 cents, Sascha
1. Sollte das Wiederholte anfordern/empfangem über HTTP verhindert werden.
2. Kann man seinen RSS auch automatisch generieren und so per URL-Parameter die Anzahl der Items bzw. das Startdatum bestimmen.
3. Ist das wahrlich nur für Desktopreader interessant, und weil eRONA webbasiert ist, interessiert es mich nicht Das gilt natürlich genauso für alle anderen webbasierten Aggregatoren.
just my 2 cents, Sascha
Entweder so, oder noch weiter: Warum nicht für jedes RSS Item eine eindeutige ID generieren, nennen wir sie mal Message-ID. Dann könnte man ein Protokoll etablieren, in dem der Sender einem Empfänger mitteilt, welche Nachrichten er hat, etwa indem er in einer IHAVE-Nachricht einen Haufen IDs mitteilt, die er schon (seit dem soundsovielten) hat. Und der Empfänger könnte mit einer passenden SENDME-Nachricht die IDs von Nachrichten mit, die er noch braucht. Das würde sogar ein nichtlineares Feeden erlauben, bei dem Lücken und Auslassungen möglich sind.
Auch das dauernde Gepolle muß ja nicht sein. Man könnte Konzentratoren haben, die die Streams von einem Haufen Blogs in einer Reihe von Kanälen, nennen wir sie mal GROUPS, kanalisieren. Dann brauche ich nicht wild durch die Pampa zu pollen, sondern könnte von einem UPSTREAM FEED alle die GROUPS bestellen (wir nennen das mal SUBSCRIBEN), die ich haben will. Von dort bekomme ich dann alle Artikel, deren IDs ich noch nicht habe.
Jeder Empfänger einer GROUP könnte die dort drin enthaltenen Artikel weiterleiten, über die IDs ist das ja eindeutig entscheidbar, ob ich den schon habe oder nicht, egal wo der her kommt. Ich könnte dieselbe GROUP also durchaus von mehr als einem FEED ziehen - ich würde den Artikel automatisch vom schnellsten Feed bekommen, ohne mir Gedanken über Routen machen zu müssen.
Ja, der Sender könnte mir den Feed sogar reinstecken, ohne daß ich das anfordere, wenn mir danach ist. Ich brauche nicht mehr zu pollen, sondern kriege Artikel vom UPSTREAM FEED sobald sie neu erschienen sind. Man müßte nur einen Port dafür reservieren - 119 zum Beispiel wäre aus verschiedenen Gründen eine gute Wahl.
Kristian
Gründer der blog.de.koehntopp.kris.* Hierarchie und potentieller Subscriber von blog.de.supergarv.garvin.*
Auch das dauernde Gepolle muß ja nicht sein. Man könnte Konzentratoren haben, die die Streams von einem Haufen Blogs in einer Reihe von Kanälen, nennen wir sie mal GROUPS, kanalisieren. Dann brauche ich nicht wild durch die Pampa zu pollen, sondern könnte von einem UPSTREAM FEED alle die GROUPS bestellen (wir nennen das mal SUBSCRIBEN), die ich haben will. Von dort bekomme ich dann alle Artikel, deren IDs ich noch nicht habe.
Jeder Empfänger einer GROUP könnte die dort drin enthaltenen Artikel weiterleiten, über die IDs ist das ja eindeutig entscheidbar, ob ich den schon habe oder nicht, egal wo der her kommt. Ich könnte dieselbe GROUP also durchaus von mehr als einem FEED ziehen - ich würde den Artikel automatisch vom schnellsten Feed bekommen, ohne mir Gedanken über Routen machen zu müssen.
Ja, der Sender könnte mir den Feed sogar reinstecken, ohne daß ich das anfordere, wenn mir danach ist. Ich brauche nicht mehr zu pollen, sondern kriege Artikel vom UPSTREAM FEED sobald sie neu erschienen sind. Man müßte nur einen Port dafür reservieren - 119 zum Beispiel wäre aus verschiedenen Gründen eine gute Wahl.
Kristian
Gründer der blog.de.koehntopp.kris.* Hierarchie und potentieller Subscriber von blog.de.supergarv.garvin.*
*Verfickte* Sterne!
Garvin, viel dringender als RSS ist ein *verschissener* Drecks-Preview-Button und eine Halt-Deine-Griffel-aus-meinem-Ascii-Du-Scheißblog-Taste!
Garvin, viel dringender als RSS ist ein *verschissener* Drecks-Preview-Button und eine Halt-Deine-Griffel-aus-meinem-Ascii-Du-Scheißblog-Taste!
Kristian,
da Du inzwischen auch in Deinem Blog die Diskussion geöffnet hast, weiß ich nicht so recht wo ich nun meinen Kommentar ansetzen soll. Ich tue es daher hier, wo es angefangen hat.
Zuerst einmal tut es mir leid, das Du heute wohl einen etwas nervigen Tag hattest oder Dich das Thema wirklich mächtig berührt.
Das Argument RSS vs. NNTP könnte ganze Seiten füllen. Ich nutze jedoch beides in den Umfängen, für die ich sie als gedacht denke. NNTP um sinnvoll Diskussionen zu führen und über ein Themenspektrum (Group) auf dem Laufenden zu bleiben. RSS, um meine eigenen Gedanken zu veröffentlichen und die Kontrolle darüber zu behalten. Artikel überarbeiten zu können und einfach "bei mir" zu haben. NNTP ist ein eher statisches Medium, dort kann ich nicht einfach meine Newsgroup gründen. Das könnte ich wenn ich einen eigenen NNTP-Server aufsetze, was aber wieder schwieriger ist und ein Grund warum sich Blogs durchgesetzt haben: Da kann quasi jeder sofort seine eigene Newsgroup erstellen.
Das Sternchen-Umquoten in s9y ist übrigens wirklich manchmal ärgerlich. Leider ist die Nutzung dessen in Kommentaren aber auch öfter sinnvoll, als bei dem Fall wo es bei Dir zur Fehlformatierung geführt hat. Mittelfristig wird in s9y ja sowieso wiki/BBCode/sonstwas Einzug halten um einfache Formatierung durchzuführen.
Ausserdem ermöglichst RSS via HTTP die sehr leichte Einblendung/Syndikation und Auslesung in anderen System. Sowas wäre mit NNTP nur mit erhöhtem Aufwand möglicht. Nicht umsonst wird RSS auch als Akronym für "Really Simple Syndication" genutzt. Übrigens hat kaum ein Feed-Reader oder Validator heutzutage Probleme mit 90% der erzeugten RSS 0.92/1.0/2.0 Feeds. Das hier ein Versionswirrwarr entstanden ist, ist ärgerlich (wenn auch historisch begründet) - aber die Reader haben es mit "ultra-liberalen" Feedparsern gut in den Griff bekommen.
Was übrigens den großen Inhalt meines Blogs angeht: Ich gebe zu, dass meine Seite mächtig ist. Aber ich verfolge eigentlich das Ziel, alle wichtigen Infos auf einer Seite zu bieten. Unterseiten guckt sich keiner an. Die Medaillen sind eine Spielerei, das gebe ich zu, aber auch hier würde ich höchstens 2-3 Links kürzen wollen. Wer halt wirklich auf den Inhalt meines Blogs abziehlt, der liest meinen RSS-Feed.
Abgesehen ist RSS halt einfach ein de-facto Standard zum Austausch von Blog-Systemen. Da ich Bloginhalte genießen möchte, greife ich auf RSS zu. Gäbe es die Feeds als NNTP, würde ich das nutzen - aber das unterstützt die Mehrheit der Blogsysteme nicht.
Und bei s9y sehe ich meine Erweiterungen pragmatisch: Sie erleichtern das, was verbeitet ist und genutzt wird.
Viele Grüße,
Garvin.
da Du inzwischen auch in Deinem Blog die Diskussion geöffnet hast, weiß ich nicht so recht wo ich nun meinen Kommentar ansetzen soll. Ich tue es daher hier, wo es angefangen hat.
Zuerst einmal tut es mir leid, das Du heute wohl einen etwas nervigen Tag hattest oder Dich das Thema wirklich mächtig berührt.
Das Argument RSS vs. NNTP könnte ganze Seiten füllen. Ich nutze jedoch beides in den Umfängen, für die ich sie als gedacht denke. NNTP um sinnvoll Diskussionen zu führen und über ein Themenspektrum (Group) auf dem Laufenden zu bleiben. RSS, um meine eigenen Gedanken zu veröffentlichen und die Kontrolle darüber zu behalten. Artikel überarbeiten zu können und einfach "bei mir" zu haben. NNTP ist ein eher statisches Medium, dort kann ich nicht einfach meine Newsgroup gründen. Das könnte ich wenn ich einen eigenen NNTP-Server aufsetze, was aber wieder schwieriger ist und ein Grund warum sich Blogs durchgesetzt haben: Da kann quasi jeder sofort seine eigene Newsgroup erstellen.
Das Sternchen-Umquoten in s9y ist übrigens wirklich manchmal ärgerlich. Leider ist die Nutzung dessen in Kommentaren aber auch öfter sinnvoll, als bei dem Fall wo es bei Dir zur Fehlformatierung geführt hat. Mittelfristig wird in s9y ja sowieso wiki/BBCode/sonstwas Einzug halten um einfache Formatierung durchzuführen.
Ausserdem ermöglichst RSS via HTTP die sehr leichte Einblendung/Syndikation und Auslesung in anderen System. Sowas wäre mit NNTP nur mit erhöhtem Aufwand möglicht. Nicht umsonst wird RSS auch als Akronym für "Really Simple Syndication" genutzt. Übrigens hat kaum ein Feed-Reader oder Validator heutzutage Probleme mit 90% der erzeugten RSS 0.92/1.0/2.0 Feeds. Das hier ein Versionswirrwarr entstanden ist, ist ärgerlich (wenn auch historisch begründet) - aber die Reader haben es mit "ultra-liberalen" Feedparsern gut in den Griff bekommen.
Was übrigens den großen Inhalt meines Blogs angeht: Ich gebe zu, dass meine Seite mächtig ist. Aber ich verfolge eigentlich das Ziel, alle wichtigen Infos auf einer Seite zu bieten. Unterseiten guckt sich keiner an. Die Medaillen sind eine Spielerei, das gebe ich zu, aber auch hier würde ich höchstens 2-3 Links kürzen wollen. Wer halt wirklich auf den Inhalt meines Blogs abziehlt, der liest meinen RSS-Feed.
Abgesehen ist RSS halt einfach ein de-facto Standard zum Austausch von Blog-Systemen. Da ich Bloginhalte genießen möchte, greife ich auf RSS zu. Gäbe es die Feeds als NNTP, würde ich das nutzen - aber das unterstützt die Mehrheit der Blogsysteme nicht.
Und bei s9y sehe ich meine Erweiterungen pragmatisch: Sie erleichtern das, was verbeitet ist und genutzt wird.
Viele Grüße,
Garvin.
Sascha,
1. Unter anderem darum geht es ja. Um die Unterstützung des HTTP IF-MODIFIED-SINCE Protokolls und dem Senden des entsprechenden Headers.
2. In serendipity wird der RSS Feed automatisch erstellt. Der URL-Parameter ist nun dank der HTTP-Unterstützung überflüssig. Ein Zeitdatum konnte auch vorher schon übermittelt werden, und alternativ auch "alle" Artikel.
3. Das ist so nicht richtig. Gerade für Aggregatoren wie bloglines oder erona ist die Bandbreitenfrage doch noch wichtiger. Gerade solche Robots sollten den modified-Header übertragen um so nur aktuelle Feeds zu erhalten. Bloglines z.B. sendet den Header, und kriegt daher auch nur noch neue Einträge, oder einen 304 Header bei unveränderten Daten.
Hoffe, das klärt etwas auf.
Grüße,
Garvin.
1. Unter anderem darum geht es ja. Um die Unterstützung des HTTP IF-MODIFIED-SINCE Protokolls und dem Senden des entsprechenden Headers.
2. In serendipity wird der RSS Feed automatisch erstellt. Der URL-Parameter ist nun dank der HTTP-Unterstützung überflüssig. Ein Zeitdatum konnte auch vorher schon übermittelt werden, und alternativ auch "alle" Artikel.
3. Das ist so nicht richtig. Gerade für Aggregatoren wie bloglines oder erona ist die Bandbreitenfrage doch noch wichtiger. Gerade solche Robots sollten den modified-Header übertragen um so nur aktuelle Feeds zu erhalten. Bloglines z.B. sendet den Header, und kriegt daher auch nur noch neue Einträge, oder einen 304 Header bei unveränderten Daten.
Hoffe, das klärt etwas auf.
Grüße,
Garvin.
3. Nö. eRONA hat magpie unter der Haube, und holt erstmal nur die HEADs, um das Datum vergleichen zu können mit der letzten lokalen Kopie.
Sascha:
Das wird dann aber vermutlich Probleme mit einigen Seiten machen. Mein Apache ist aufgrund dem Zusammenspiel von TurckMMCache und phpOpenTracker dazu verdammt, immer ein "no cache" Pragma, LastModified = NOW und anderes zu schicken, so dass ein HEAD-Request Dir immer sagen wird, es gäbe was neues. Ich kenne einige Server (bei denen ein RSS dynamisch generiert wird), wo das ähnlich ist.
Ich habe aber in meinen Logfiles einige MagPieRSS-Requests gesehen, die den ETAG/IF_MODIFIED_SINCE Header verwenden, daher gehe ich davon aus, dass es das unterstützt?!
Grüße, Garvin.
Das wird dann aber vermutlich Probleme mit einigen Seiten machen. Mein Apache ist aufgrund dem Zusammenspiel von TurckMMCache und phpOpenTracker dazu verdammt, immer ein "no cache" Pragma, LastModified = NOW und anderes zu schicken, so dass ein HEAD-Request Dir immer sagen wird, es gäbe was neues. Ich kenne einige Server (bei denen ein RSS dynamisch generiert wird), wo das ähnlich ist.
Ich habe aber in meinen Logfiles einige MagPieRSS-Requests gesehen, die den ETAG/IF_MODIFIED_SINCE Header verwenden, daher gehe ich davon aus, dass es das unterstützt?!
Grüße, Garvin.
Alp Uçkan\'s Website am : Conditional Get bei RSS-Feeds
Vorschau anzeigen
Die wunderbare Welt von Isotopp am : Wir sind so geil, ...
Vorschau anzeigen