RSS updates - "rewrite" oder "add"??
bleicher
- xml
Шалом , друзі!
Ich habe ehrlich versucht eine Antwort zu googeln , aber obwohl "RSS-bastelanleitungen" in Scharen zu finden sind , stand doch nirgendwo wie man die RSS-dateien richtig Updated. Addiert man einfach ein neues <item> oder schreibt man die Datei komplett neu?Bzw. wie reagieren RSS-feed reader auf beide versionen üblicherweise?
Wäre dankbar wenn mich jmnd. aufklären würde.
Danke im Voraus.
hi,
Ich habe ehrlich versucht eine Antwort zu googeln , aber obwohl "RSS-bastelanleitungen" in Scharen zu finden sind , stand doch nirgendwo wie man die RSS-dateien richtig Updated. Addiert man einfach ein neues <item> oder schreibt man die Datei komplett neu?
Wo wäre der Unterschied?
Wenn dein RSS-Feed eine statische Datei ist, dann speicherst du sie doch in jedem Falle neu, wenn du etwas hinzufügst.
Anders bei dynamisch generiertem Feed - da ändert sich idR. die Auswahl der Items automatisch, weil man einfach die letzten X Stück nimmt und in den Feed packt.
Bzw. wie reagieren RSS-feed reader auf beide versionen üblicherweise?
Die von dir genannten Versionen sind nur eine.
Und wie soll ein Reader schon reagieren - er zeigt die Items an, die der Feed aktuell enthält - und ggf. noch ältere, die er jetzt nicht mehr enthält, wenn er sie irgendwie (zwischen-)gespeichert hat.
gruß,
wahsaga
Hallo,
Ich habe ehrlich versucht eine Antwort zu googeln , aber obwohl "RSS-bastelanleitungen" in Scharen zu finden sind , stand doch nirgendwo wie man die RSS-dateien richtig Updated. Addiert man einfach ein neues <item> oder schreibt man die Datei komplett neu?Bzw. wie reagieren RSS-feed reader auf beide versionen üblicherweise?
Wenn es Dir nur darum geht, den Feed als solches zu updaten, dann packt man einfach ein neues item-Element hinein. Und um den Feed nicht ewig zu wachsen lassen, schmeisst man bei einer bestimmten Anzahl auch wieder die ganz alten item-Elemente hinaus, damit das Ding nicht zu groß wird. Aber das hat wahsaga ja schon erzählt.
Interessanter ist die Frage, was passiert, wenn Du in einem Item in einem Feed einen Fehler findest oder es aus irgendeinem anderen Grund updaten will. Um zu verstehen, was man da am besten machen sollte, muss man sich mal für ein Gedankenbeispiel in die Arbeitsweise eines Feedreaders hineinversetzen.
Mal angenommen der Römische Senat hätte folgenden Feed publiziert:
<rss version="2.0">
<channel>
<title>Ciceros Karriere</title>
<link>http://spqr.example/annales/cicero</link>
<description>Ciceros Weg durch die Magistrate</description>
<item>
<title>Ädilat</title>
<description>Im Jahre des Konsulats von Gaius Pompeius Magnus und Marcus
Licinius Crassus Dives wurde Cicero zum kutulischen Ädil gewählt.
</description>
</item>
<item>
<title>Quaestur</title>
<description>Im Jahre des Konsulats von Lucius Octavius und Gaius Aurelius
Cotta wurde Cicero zum Quaestor gewählt.
</description>
</item>
</channel>
</rss>
Irgendein antiker Feedreader – sagen wir mal aus Griechenland – hatte sich diesen Feed nun sagen wir mal im Jahre 69 v. Chr. heruntergeladen und speicherte diese Informationen in seiner Datenstruktur. Mal sehr symbolisch dargestellt:
• Item 2: • Titel: "Ädilat" • Beschreibung: "Im Jahre des Konsulats von Gaius Pompeius Magnus und Marcus Licinius Crassus Dives diente Cicero als kutulischen Ädil." • Datum: 69 v. u. Z. • Item 1: • Titel: "Quaestur" • Beschreibung: "Im Jahre des Konsulats von Lucius Octavius und Gaius Aurelius Cotta diente Cicero als Quaestor." • Datum: 69 v. u. Z.
(Nebenbei bemerkt, ehe jetzt jemand meckern sollte, die Quaestur Ciceros sei doch früher gewesen: Ja das stimmt. Nur bietet mir das Datumformats von RSS 2.0 nach RFC 822 keine negativen Jahre an. Alternative Datumsschreibweisen nach RFC 3339 und dessen Verwandten übrigens auch nicht. Die im Web gebräuchlichen Profile von ISO 8601 bieten keine Möglichkeit für Timestamps vor unserer Zeitrechnung an. J'accuse!)
Im Dezember des Jahres 69 v. u. Z. fällt den Sklaven den Pontifex Maximus auf, dass sie zum Beginn des Jahres bei der Erstellung des RSS Feeds Ciceros einen Fehler gemacht haben – sie haben das Jahr seines Ädilates falsch angegeben, nämlich ein Jahr früher. Also verbessern sie schnell den Feed:
<rss version="2.0">
<channel>
<title>Ciceros Karriere</title>
<link>http://spqr.example/annales/cicero</link>
<description>Ciceros Weg durch die Magistrate</description>
<item>
<title>Ädilat</title>
<description>Im Jahre des Konsulats von Quintus Hortensius Hortalus und
Quintus Caecilius Metellus Creticus wurde Cicero zum kutulischen Ädil
gewählt.
</description>
</item>
<item>
<title>Quaestur</title>
<description>Im Jahre des Konsulats von Lucius Octavius und Gaius Aurelius
Cotta wurde Cicero zum Quaestor gewählt.
</description>
</item>
</channel>
</rss>
Es hat sich nur der Inhalt des description-Element des ersten item-Elementes geändert. In der unbekannten griechischen Provinz wird nun der hypothetische Feedreader angeworfen, ruft den Feed ab, parst ihn und versucht diesen in seine bereits bestehende Datenstruktur einzuordnen:
Was ist also zu tun, irgendwie will die empfangene Information ja einsortiert und präsentiert werden:
a) Es könnte ein neuer Eintrag im Feed sein, also legt er ein Item 3 an. Das wäre zwar falsch, aber der Feedreader kann es nicht wissen. b) Der Feedreader ersetzt die Informationen von Item 2 in seiner Datenstruktur durch neuen geänderten Informationen. Das wäre das gewünschte Ergebnis. Aber woher soll der der Feedreader wissen, dass der früher empfangene und der jetzt empfangene Eintrag im Feed ein- und derselbe sind bzw. dasselbe Ereignis behandeln.
Der Feedreader ist Software. Der kann also nicht soviel aus dem Kontext schließen, wie wir, um bei solchen Dilemmas auf die richtige Entscheidung zum kommen. Er weiss zum Beispiel nicht, dass – würde er Möglichkeit (a) wählen – die dargestellte Information dann gegen drei Prinzipien des Römischen Rechts verstoßen würde. Alles, was er hat, ist die übermittelte Information, deren Bedeutung er kaum bis nicht versteht, also auch nicht richtig agieren kann, wenn sich diese Information ändert. Und tatsächlich kann sich all die inhaltstragende Information eines item-Elementes in einem RSS-Feed ändern:
<item>
<title>...</title>
<link>...</link>
<description>...</description>
<author>...</author>
<category>...</category>
<pubDate>...</pubDate>
</item>
Die title- und description-Elemente können immer mal wieder verändert werden. Ist ja nur Text, da können sich auch Rechtschreibfehler einschleichen, die nachher verbessert werden. Mal ganz abgesehen von von größeren Updates. Die Elemente author und category? Einträge können nachträglich neue Kategorien bekommen, Autoren können sich beim Ändern verändern oder eine neue Mailadresse kriegen. Ein Eintrag kann neu datiert werden. Selbst das Link-Element kann sich verändern – Umzug auf eine neue Domain z.B. Letztendlich ist keines der inhaltstragendes Elemente als ständige Identifikation eines Feed-Eintrages geeignet, da sich alle verändern können.
Es gibt natürlich Strategien, die die gebräuchlichen Feedreader verwenden, um Duplikate oder kleinere Änderungen herauszufinden. Das Verfolgen eines Items im Feed über längere Zeit, das Ausmass der Veränderungen, die Levenshtein-Distanz. Oder auch manchen Elementen mehr Wichtigkeit zuzuweisen. Wie James Holderness herausgefunden hat, ist unter populären Feedreadern das link-Element als Identifikationsmerkmal besonders beliebt, Dave Winer dagegen empfiehlt das title-Element, mit abenteuerlicher Begründung, wie ich finde. Aber all diese Strategien sind Heuristiken, vereinfacht gesagt rät der Feedreader. Es ist reines Raten, Sicherheit erlangt er dadurch nicht.
Es gibt eine Möglichkeit, dem Feedreader Sicherheit zu geben. Das passende Element nennt sich guid, das steht für Global Unique ID. Eine global eindeutige ID. Sieht z.B. so aus:
<item>
<title>...</title>
<link>...</link>
<guid>tag:tepasse.org,2006-09-08:rss/guid-beispiel</guid>
</item>
Im Prinzip kann man zwischen <guid> und </guid> jeglichen Text packen. Aber man will ja dafür sorgen, dass ein bereits einmal empfangener Eintrag eines Feedes in einem Feedreader niemals mehr als Duplikat auftaucht, also sollte man ein paar Dinge beachten:
Plus die Sonderregel, wenn man damit rechnet, dass Einträge des eigenen angebotenen Feed in anderen Feeds nochmal auftauchen, als Zusammenstellung von Aggregatoren oder Planets:
Es gibt verschiedene Varianten so eine Eindeutigkeit zu erreichen, z.B. das Nutzen eines UUID oder einer entsprechenden URI. Gerne wird auch einfach der Permalink des Eintrages genommen:
<guid isPermaLink="true">http://spqr.example/annales/cicero/praetor</guid>
Wieder anderen geht das nicht weit genug und sie wollen noch einen Zeitstempel mit hinein nehmen, denn die Domain der HTTP URI könnte sich ja ändern. Mark Pilgrim hat einen recht lesenswerten Essay geschrieben, wie man eine ID für Atom bastelt, er landet dann bei Tag URIs. Der Essay ist auch ohne weiteres auf guid-Elemente in RSS 2.0 anwendbar.
...
Fazit: Wenn man als Anbieter eines Feeds damit rechnet, dass man seine Einträge nach der Veröffentlichung noch verändert, sollte man diese zwei Dinge tun:
...
Ach ja: Das andere Feed-Format Atom 1.0 hat (GU)IDs übrigens als verpflichtend im Feed integriert und bietet noch zusätzlich ein Element namens „updated“ an, mit dem man das letzte Update eines Elementes signalisieren kann – und gleichzeitig nicht auf das Dateum der allererster Veröffentlichung verzichten muss:
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Tim's Pamphlete über Feeds</title>
<autor>
<name>Tim Tepaße</name>
<uri>http://tepasse.org/</uri>
</autor>
<id>tag:tepasse.org,2006-09-08:feedpamphlete</id>
<entry>
<title>Die Wichtigkeit von GUIDs</title>
<link rel="alternate">http://forum.de.selfhtml.org/my/?t=136291&m=885052</link>
<summary>Tim schreibt wieder zuviel und macht zuviele
Rechtschreibfehler.</summary>
<id>tag:tepasse.org,2006-09-08:feedpamphlete/guids</id>
<published>2006-09-08T03:53+02:00</published>
<updated>2006-09-08T03:57+02:00</updated>
</entry>
</feed>
Tim
Hallo Tim.
--
Gleich mal die neue Kategorie einweihen.
Fein gemacht.
Einen schönen Freitag noch.
Gruß, Mathias