nicht angemeldet
Podcast: Wieviele Einträge?
Guten Abend!
Für den/das Blog zu meiner Radiosendung entwickele ich gerade ein Jlog-Plugin, mit dem automatisch Podcasts erstellen kann. Die technische Spezifikation von Apple konnte bereits die meisten Fragen, nur eines ist bislang immer noch unbeantwortet:
Wieviele Einträge (einzelne Tracks) sollte der Feed enthalten (verlinken):
• alle bisher veröffentlichten
• die letzten n
Wie handhabt ihr das, gibt es Empfehlungen oder vielleicht sogar eine entsprechende Spezifikation, die ich übersehen habe?
Ich wünsche einen guten Start in die Woche!
-
Hallo,
Wieviele Einträge (einzelne Tracks) sollte der Feed enthalten (verlinken):
Irgendwo habe ich gelesen, dass man die letzten 15 da reinmachen soll, also bei RSS und Atom. Ob das jetzt konkret bei Podcasts irgendwie anders ist weiß ich aber nicht.
Jeena
-
hi,
Die technische Spezifikation von Apple konnte bereits die meisten Fragen, nur eines ist bislang immer noch unbeantwortet:
Wieviele Einträge (einzelne Tracks) sollte der Feed enthalten (verlinken)
Die Podcast-Spezifikation von Apple verweist lediglich auf die RSS 2.0 Spezifikation (http://blogs.law.harvard.edu/tech/rss), und die besagt:
"A channel may contain any number of <item>s."Eine weitergehende Einschränkung kann ich bei Apple auf der genannten Seite nicht finden.
• alle bisher veröffentlichten
• die letzten nWie handhabt ihr das, gibt es Empfehlungen oder vielleicht sogar eine entsprechende Spezifikation, die ich übersehen habe?
Alle bisherigen halte ich für wenig sinnvoll.
Podcasts und Feeds werden bei Interesse idR. abonniert - jedes mal die komplette Historie mitzuschicken, wäre also nur traffic-intensiv, ohne dem Benutzer einen konkreten Mehrwert zu bieten.
(Falls trotzdem Nutzer an der vollen Historie interessiert sind, könnte man dafür ggf. einen separaten Feed-URL anbieten, der alles liefert - ggf. mit der zusätzlichen Bitte, diesen nicht zu abonnieren, sondern nach dem einmaligen Abruf dann auf den "aktuellen" Feed zu wechseln.)Ob man nun fünf, zehn oder 15 Items aufnehmen will - hängt nicht zuletzt von der Frequenz ab, in der neue Beiträge hinzukommen.
Ist das nur ein mal die Woche, reichen vermutlich fünf - ist es ein neuer alle halbe Stunde, könnten auch 15 noch zu wenig sein.Da könnte man dann noch überlegen, ob man Mechanismen von HTTP wie Last-Modified nutzt - um dann den Programmen, die sowas unterstützen, alles Neue seit dem letzten Abruf zu liefern, also die Anzahl der Items pro Feedabruf individuell pro Nutzer (resp. Client) regulieren, wenn sinnvoll.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Moin!
Wieviele Einträge (einzelne Tracks) sollte der Feed enthalten (verlinken)
Die Podcast-Spezifikation von Apple verweist lediglich auf die RSS 2.0 Spezifikation (http://blogs.law.harvard.edu/tech/rss), und die besagt:
"A channel may contain any number of <item>s."Deshalb liebe ich Atom: Es ist präziser, reines XML und konsequenter.
• alle bisher veröffentlichten
• die letzten nAlle bisherigen halte ich für wenig sinnvoll.
Podcasts und Feeds werden bei Interesse idR. abonniert - jedes mal die komplette Historie mitzuschicken, wäre also nur traffic-intensiv, ohne dem Benutzer einen konkreten Mehrwert zu bieten.Das spricht an sich ja schon einmal für die zweite genannte Lösung.
(Falls trotzdem Nutzer an der vollen Historie interessiert sind, könnte man dafür ggf. einen separaten Feed-URL anbieten, der alles liefert - ggf. mit der zusätzlichen Bitte, diesen nicht zu abonnieren, sondern nach dem einmaligen Abruf dann auf den "aktuellen" Feed zu wechseln.)
Diese Lösung lässt sich – sofern man die Spezifikation von Apple nimmt – mit Hilfe des RSS Feed Tags
<itunes:new-feed-url>sogar recht bequem realisieren:This tag allows you to change the URL where the podcast feed is located.
Ob man nun fünf, zehn oder 15 Items aufnehmen will - hängt nicht zuletzt von der Frequenz ab, in der neue Beiträge hinzukommen.
Ist das nur ein mal die Woche, reichen vermutlich fünf - ist es ein neuer alle halbe Stunde, könnten auch 15 noch zu wenig sein.Die Radiosendung kommt monatlich, von daher wohl eher 5, oder?
Da könnte man dann noch überlegen, ob man Mechanismen von HTTP wie Last-Modified nutzt - um dann den Programmen, die sowas unterstützen, alles Neue seit dem letzten Abruf zu liefern, also die Anzahl der Items pro Feedabruf individuell pro Nutzer (resp. Client) regulieren, wenn sinnvoll.
Ich werde mal darüber nachdenken, aber in der anvisierten Ausführung wird das erst einmal nicht zum Plugin gehören, weil ich damit ja „die nächste Dose mit Würmer aufmache“.
Schönen Montag,
Robert -
Hallo Wahsaga,
Da könnte man dann noch überlegen, ob man Mechanismen von HTTP wie Last-Modified nutzt - um dann den Programmen, die sowas unterstützen, alles Neue seit dem letzten Abruf zu liefern, also die Anzahl der Items pro Feedabruf individuell pro Nutzer (resp. Client) regulieren, wenn sinnvoll.
Wobei das dann nicht unbedingt Last-Modified im HTTP-Sinne ist, vor allem kann diese Variante allein mit Last-Modified auch mit Proxys und Caches in Konflikt kommen, da diese nur mit einem Hash des gesamten Inhaltes arbeitet.
Man nennt das Delta Encoding: man verschickt das Delta zwischen Zeitpunkt V(ergangenheit) und Zeitpunkt J(etzt) - aber dieses Delta zu berechnen ist nun mal sehr spezifisch für den jeweiligen Content, deswegen kann HTTP keine Aussagen dazu machen. Es gibt sogar einen (leicht abstrakten) RFC dazu. Auf diesem RFC basierend wurde dann auch ein Delta Encoding für RSS und Atom angedacht.
Das ganze ist natürlich noch sehr experimentell und noch nicht sehr weit verbreitet. Der Autor eines Wordpress Plugins für diese Technik stolperte z.B. über einen Bug in Apachen und ähnliches. Sprich auf Seiten von Feedreadern und auf der Seite von Feed-Anbietern ist das noch nicht sehr weit verbreitet. Aber hey, ein Lichtblick: Microsofts Feed Download Maschine unterstützt es. D.h. vielleicht setzt es sich durch. Es braucht nur mal einen besseren Standard als nur einen Weblogeintrag. ;)
Tim
-
-
Hallo Robert,
Wieviele Einträge (einzelne Tracks) sollte der Feed enthalten (verlinken):
• alle bisher veröffentlichten
• die letzten nIch plädiere aus gesundem Menschenverstand auch für ein N, wobei Du oder der Benutzer des Plugins entscheiden sollte, wie groß N ist. Man stelle sich einen Feed der einer Zeitung vor, die seit hundert Jahren Artikel veröffentlicht. ;)
Um Jeenas „15" mal in einen Kontext zu setzen: Das originale RDF-basierte RSS 0.9 von Netscape hatte eine Limitierung von 15 Einträgen (items) in einem Feed, das nicht mehr RDF-basierte RSS 0.91 von Netscape auch. Als Dave Winer bzw. seine Firma Userland Software dann RSS übernahm und ein minimal anderes RSS 0.91 publizierte, wurde die Limitierung fallen gelassen und tauchte in der Userland-Dialekten von RSS (RSS 0.9x, RSS 2.0) nicht mehr auf.
Das wiederum RDF-basierte RSS 1.0 gibt nur noch die Empfehlung sich aus Kompabilitätsgründen auf 15 Einträge zu beschränken.
Wie handhabt ihr das, gibt es Empfehlungen oder vielleicht sogar eine entsprechende Spezifikation, die ich übersehen habe?
Nein. Selbst das Atom Publishing Protocol, das (aus Notwendigkeit) eine Möglichkeit anbietet, die über APP erreichbaren „Collections“ (Die Gesamtheit aller Einträge, Podcasts, whatever) in mehrere Feeds (von jeweils n Einträgen) aufzuteilen macht keine Angabe zu einer Größe.
Für mich ist das Thema weniger durch Spezifikationen sondern mehr durch etwas technische Notwendigkeit (zu große Feeds) und viel mehr durch Benutzerfreundlichkeit definiert. Und zwar gilt für mich für Feeds dasselbe, was auch für die Startseite des Weblogs, des Podcasts, des Wasauchimmers gilt: Man begrenzt es bei einem Wert n.
Wie der Wert n zu kalkulieren ist, hängt da von Thema ab. Letztendlich soll so eine Startseite ja die Möglichkeit geben, einen Eindruck zu gewinnen, ob es sich lohnt, die Publikation dauerhaft zu verfolgen. Denselben Eindruck gewinnt man dadurch auch im Feedreader. Und so gelten auch dieselben ad-hoc-Regeln: Bei Publikationen mit hoher Fluktuation und kleineren Einträgen empfiehlt sich ein größeres n, weil man dann mehr Inhalt für den Gesamteindruck braucht. Bei Publikationen mit geringer Fluktuation und größeren Einträgen ist eventuell ein kleineres n angebracht, weil schon soviel Inhalt da ist, der einen Eindruck vermittelt. Letztendlich ist es nur nach der Regel Pi mal Daumen zu ermitteln, wobei die Größe des Daumens stark von dem angebotenen Inhalt abhängt.
Tim