RSS updates - "rewrite" oder "add"??

[bleicher]

Шалом , друзі!
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.

[wahsaga]

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

[Tim Tepaße]

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:

1. Der Feedreader findet zwei item-Elemente in dem Feed vor.
2. Das zweite Element in dem Feed kann er durch vergleichen der Datenstrukturen    mit dem bereits gespeicherten Item 1 in Verbindung setzen – es ist offenbar    das Gleiche Element. Also präsentiert der Feedreader das Item nicht als neu    ungelesen.
3. Wenn er aber das erste Element in dem Feed mit bereits gespeicherten    Datenstrukturen vergleicht, bekommt er nur einen teilweisen Treffer: Nur der    Titel ist gleich geblieben.

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:

1. Man sollte die GUID eines Eintrages später niemals verändern – denn dann hält    der Feedreader den veränderten Eintrag für einen anderen oder neuen Eintrag.
2. Man sollte die GUID eines Eintrages niemals noch einmal verwenden – denn dann    hält der Feedreader einen neueren Eintrag eventuell für das Update einen    bereits empfangenen Eintrages.

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:

3. Man könnte dafür sorgen, dass die GUID auch das „G“ in ihrem Akronym beachtet,    nämlich, dass sie wirklich global eindeutig ist und von niemanden sonst    benutzt werden kann – denn sonst verwechselt der Feedreader womöglich eigene    mit fremden Elementen.

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:

1. Jeden, aber auch jeden Eintrag mit einer GUID ausstatten, die obige Regeln befolgt.
2. Beim ändern das Element <pubDate> anpassen.

...

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&amp;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

[Mathias Brodala]

Hallo Tim.

--
Gleich mal die neue Kategorie einweihen.

Fein gemacht.

Einen schönen Freitag noch.

Gruß, Mathias