nicht angemeldet
Hallo Ihr zwei,
Ist zwar ein Argument - aber dann sollte man vielleicht überlegen, ob für solche "Archive" RSS/ATOM das richtige Medium sind.
Es gibt Leute, die meinen, dass das Atom Ökosystem genau das richtige ist und machen Vorschläge für den [http://girtby.net/offerings/atomexport](träumen von einem Atomstore (Einer Datenbank für Atom-Entry-Dokumente, zugänglich über das Atom Publishing Protocol) und). (Andere träumen gleich von einem Atomstore (Einer Datenbank für Atom-Entry-Dokumente, zugänglich über das Atom Publishing Protocol).
Man könnte vielleicht einen von-Anbeginn-der-Zeit-einfach-alles-Feed _zustzlich_ anbieten - wobei man sich auch dann wieder Gedanken machen sollte, wie man es ggf. regeln kann, dass dieser nur einmalig, und nicht permanent abgerufen wird.
Abgesehen von obigen Träumen, bietet das Atom Publishing Protocol genau dafür Mechanismen. Zur Erinnerung: APP bietet eine RESTige API mit Atom als Datenformat für CRUD-Operationen auf Kollektionen. Übersetzt: Wenn man eine Collection lesen will, nutzt man einfach HTTP und macht einen GET auf eine URI und kriegt einen Atom-Feed zurück, der dann einzelne Einträge enthält oder auf diese verweist. Sprich: Beim Lesen gibt es keinen Unterschied zwischen einem normalen Atom-Feed und einem Zugriff mittels APP.
Nun ist in APP auch gleichzeitig der Zugriff auf nicht vollständige Collections definiert – schließlich will man nicht einen riesigen Feed runterladen. Konsequenterweise gibt es eine Möglichkeit sich aus einem Feed, der nur einen Ausschnitt einer Collection, anhand von Links zu weiteren Ausschnitt-Feeds entlangzuhangeln und somit clientseitig die Collection zu vervollständigen:
~~~xml
<feed xmlns="http://www.w3.org/2005/Atom">
<link rel="first"
href="http://example.org/entries/go" />
<link rel="next"
href="http://example.org/entries/2" />
<link rel="last"
href="http://example.org/entries/10" />
...
</feed>
Sprich: Bietet der Anbieter des Weblogs diese Möglichkeit an, muss ein Feedreader nur diese Möglichkeit aus dem Atom Publishing Protocol unterstützen, um den Feed mit mehreren (vielen) Requests zu vervollständigen. Das ist nicht so Zukunftsvision, wie man denkt. Google hat sein GData-Protokoll ja auf Atom und APP aufgebaut. Dort wird das schon fleissig [genutzt](http://code.google.com/apis/gdata/reference.html#Queries). Idealerweise kennt ein Feedreader also das Atom Publishing Protocol.
Da das eventuell etwas zuviel sein mag, wurde diese Funktionalität in einem weiteren [Internet Draft](http://www1.tools.ietf.org/wg/atompub/draft-nottingham-atompub-feed-history-11.txt) kopiert und durch explizite Link-Relationen für Archiv-Feeds erweitert. Technisch gesehen sind die Spezifikationen dafür also durchaus bereit. Es mangelt nur an der Software. ;)
Tim