Diesmal beleuchten wir mit Andreas Hubel und Tim Pritlove das, was einen Podcast ausmacht: den RSS Feed. Dabei springen wir zurück an den Anfang der 2000er und sehen uns an, was sich seitdem im Zusammenhang mit Standards und Spezifikationen getan hat und welche aktuellen Entwicklungen im Zusammenhang mit PodloveIndex.org es gibt.
Das war für mich die vielleicht interessanteste Episode bislang. Leider auch die einzige, die mich mit sehr gemischten Gefühlen zurücklässt. Grund dafür sind Voten zum Podcastindex.
Vorab: Auch wenn es mir umgekehrt wohl lieber wäre, spreche ich den Bestrebungen des Podcastindex aktuell grössere Verbreitungschancen zu als jenen von Podlove. Weiter bin ich kein Entwickler. Urteile, welche Herangehensweise die technisch beste sei, masse ich mir deshalb nicht an.
Die Kritik am Podcastindex wird primär am Chapters Tag aufgehängt, während die übrigen Podcastindex Tags kaum kritisiert oder gar für gut befunden werden. Ist die Jason JSON-Herangehensweise blöd? Möglich. Ich weiss es nicht. Umgekehrt sehe ich Folgendes: Nie hatten Kapitelmarken eine bessere Chance, sich von Audiodateien und Audiodateiformaten zu lösen. Vielleicht sollten wir uns des Spatzen in der Hand erfreuen, statt der Taube auf dem Dach nachzutrauern. Letztlich ist ein Standard nur wirklich wertvoll, wenn er ein Standard ist.
Auch will ich unterstreichen, dass sich nach wie vor jede*r zum Podcastindex und insbesondere zum Namespace äussern kann. Alle können bestehende Ideen bei GitHub öffentlich kritisieren und bessere oder neue präsentieren. Selbst ich als kleiner Fisch in der globalen Podcastlandschaft konnte mich vereinzelt einbringen und wurde ernst genommen.
Wir meckern sehr gerne über die Amerikaner. Da bin auch ich nicht unschuldig. Hier öffnen sie (zusammen mit Briten, Australiern, Dänen, etc.) uns (und allen anderen) jedoch die Tür und bieten Hand für gemeinsame Lösungen. Insofern kann man ihnen kaum Vorwürfe machen. Dies wäre die Gelegenheit, endlich an einem gemeinsamen Strang zu ziehen und Podlove-Ideen sichtbar(er) zu machen.
Vor diesem Hintergrund würde ich den vorgeschlagenen Stinkefinger-Weg eher im Bereich “vergebene Liebesmüh bis kontraproduktiv” einordnen. Brauchen wir noch einen eigenen Namespace, zu dem wir jetzt schon ankündigen, dass ihn niemand sehen wird, während wir regelmässig mitteilen, dass unser Zeitbudget knapp und Hilfe von aussen erwünscht ist?
@timpritlove: Du hast zweifelsfrei ein grosses Wissen über die Podcastlandschaft, Visionen, Ideen und technisches Know-How. Super! Auch sagst Du, diverse überfällige “low hanging fruits” zu kennen. Damit wärst Du doch der ideale Kandidat, um den Podcastindex zu bereichern. Warum diese Ideen nicht dem Index präsentieren und dort einpflegen? Die Chance, dass diese Früchte endlich gepflückt werden, sehe ich so am grössten. Das muss doch das Ziel sein, auch wenn letztlich nicht sichtbar “Podlove” dran klebt? Stattdessen klammheimlich den neuen deutschen Stinkefinger-Namespace zu gründen, halte ich aktuell für weniger zielführend.
Vielleicht habe ich zwischen den Zeilen einen Unterton missverstanden. Ich meine jedoch, hier einen gewissen Stolz zu spüren, der einer gemeinsamen Lösung im Weg stehen könnte. Das fände ich schade. Natürlich lasse ich mich gerne korrigieren.
Insofern will ich abschliessend eher Michaela und @ericteubert beipflichten, den Podcastindex aktiv zu verfolgen und sich einzubringen, damit dieser möglichst gut wird. Wer weiss, wann wir wieder eine derartige Chance erhalten?
Das ist ein Implementierungsdetail. Mich stört eher das in Phase 2 & 3 der ganze Finanzierungsaspekt via Kryptowährungen in den RSS Feed kommen sollen. Das hat da nichts verloren, verschiebt den Fokus und bringt den ganzen Standard in Gefahr. Da fand ich den Einspieler aus “The Feed” den Andi mitgebracht hatte sehr bezeichnend. Würde mich als Client Entwickler auch nerven wenn ich davon ausgehen muss das ich immer nur Teile der Spec implementieren kann.
Da ich die genaue Implementierungsweise von derartigen Zahlungsmöglichkeiten mangels technischem Wissen nicht durchblickt habe, kann ich mich dazu kaum äussern. Die dahinterstehende Idee, eine Finanzierungskette zu bilden, in der mehrere/alle Akteure profitieren/partizipieren können (Podcaster*in/Infrastrukturbetreiber *in /Cliententwickler *in) halte ich nicht für grundsätzlich verkehrt. Letztlich fällt das alles nicht kostenlos vom Himmel und niemand mag Werbung.
Dass sich nun auch stark darauf konzentriert wird, kann man durchaus kritisieren. Wobei ich fairerweise sagen will, dass sich die grössten Diskussionen gerade um die Location und ein Content Rating drehen.
Aber auch hier: Das darf (und soll?) frei kritisiert werden. Wir werden auch nicht davon abgehalten, stattdessen andere Themen zu pushen. Das Beispiel der Paged Feeds hat gezeigt, dass wir mit wenig Aufwand ein sinnvolles Anliegen auf einen guten Weg bringen können. Ich bin optimistisch: Wenn sich da noch 2–3 Personen anhängen, sehe ich die Paged Feeds im Trockenen.
Ich denke das war von meiner Seite näher an einem Luftlassen als am Definieren einer tatsächlichen Roadmap. Natürlich werde ich bei Bedarf eines Metadatums im Feed vorzugsweise ein Feld nehmen, das podcastindex.org definiert. Aber sollte das nicht definiert sein, finde ich es auch nicht verkehrt, erstmal irgendwas in den Feed zu werfen als wieder jahrelang darüber zu reden, wie schön es wäre, was zu haben.
Was die chapters angeht habe ich aber weiterhin kein gutes Gefühl. Aber nicht weil mein Stolz verletzt ist. Ich hab’s ja nur umgesetzt, erdacht hat die spec ein ganzer Workshop 
Wurde ja im Podcast besprochen, aber die Kritik ist vielfältig: warum JSON ist nicht nachvollziehbar. Die zusätzlichen Metadaten verkomplizieren es unnötig und senken die Chance auf eine breite Implementierung. Externe Verlinkung statt inline ist für mich die frustrierendste Entscheidung – zumal die Initiative aus Clientinteresse kam, und ich mir sicher bin, dass die es bereuen werden. Statt einem Request müssen Clients nun n+1 Requests abfeuern und bearbeiten. Das ist nicht nur komplexer zu implementieren, sondern dauert auch deutlich länger und verbraucht mehr Traffic. Besonders letzteres ist absurd, da das der genannte Grund für die Externalisierung war. Aber an die Größe von HTTP Headern hat dabei wohl niemand gedacht, die oft wohl größer sein werden als das ganze Kapitel-Dokument. Ups.
Sorry ich rante schon wieder. Ich hatte das auch schon mal in englisch begonnen um doch noch meine Perspektive after-the-fact im issue zu lassen aber das triftete auch in einen rant ab und müsste noch mal editiert werden damit’s sachlich wird 
Aber weiß auch nicht ob das so eine gute Idee ist, eine versiegelte spec noch mal mit Argumenten zu bewerfen.
Danke für deine Ergänzungen. Wie gesagt: Ob/weshalb JSON gut oder schlecht ist, kann ich nicht sagen. Ich vertraue da auf deine Einschätzung. Gleichzeitig frage ich mich, weshalb die das gewählt haben. Dumm sind die ja nicht. Irgendeinen Vorteil müssen sie ja sehen.
Ich sehe gerade nicht, weshalb das schaden sollte, solange es nicht provokant wird. Für den Fall, dass sich JSON als doofe Idee herausstellen sollte, könntest Du wenigstens darauf zeigen und Recht behalten. 
Update:
Für Phase 3 wird nun, neben alternateEnclosure, ein zu finalisierender Tag gesucht. Paged Feeds?
An sich wäre das JSON vs XML Thema auch nochmal eine eigene Folge, für mich bin ich zu dem Schluss gekommen: Wenn man JSON anbietet, dann auch gleich ne (dynamische) API, ggf. auch gleich mit GraphQL Support. Klar, braucht dann halt bei vielen Anfragen wieder Edge-Caching und man kann nicht mehr so richtig mit statischen Files arbeiten, aber dann ist man halt auch entsprechend flexibel – und ist ja auch nur für die Anwendungsfälle relevant wo der bestehende XML Feed nicht reicht. Da hab ich auch ein paar Ideen/Experimente am laufen, wer sich dafür interessiert kann sich ja mal bei mir melden.
Ansonsten, hab ich mal was für euch ausprobiert, damit ihr das nicht selbst tun müsst:
Ich hatte https://github.com/Lehmancreations/Podcast-Namespace-Wordpress-Plugin/ als ein generisches Plugin verstanden, um seinen Wordpress-Feed um Podcast Namespace Tags zu erweitern – ist aber aktuell nur für Powerpress bzw. lässt sich in der aktuellen Art nur verwenden wenn man seine einzelnen Episoden als Beiträge und nicht wie der Publisher als eigener Content Type “Episode” abbildet.
Wenn man in den Code schaut ist das wohl aber auch einfach mit nem Options Page generator zusammengeklickt, zumindest für den Anfang. Upstream Issue mit ggf. mehr Infos: https://github.com/Lehmancreations/Podcast-Namespace-Wordpress-Plugin/issues/4