Status

Available in a git repository branch.
Branch: schmonz/fancypodcast
Author: schmonz

Nothing new since 2013/07/21 merge to master.

Features

Feature iTunes RSS iTunes Atom Downcast RSS Downcast Atom
Feed image
Feed title (./) (./) (./) (./)
Feed publisher
Feed "category"
Feed date (./) (./) (./) (./)
Feed description (./) (./) (./)
Episode image
Episode title (./) (./) (./) (./)
Episode date (./) (./) (./) (./)
Episode duration
Episode author
Episode description (./) (./) (./)
Episode enclosure (./) (./) (./) (./)

Future improvements

Embedded audio/video player in browsers

  • For a given enclosure, depending on autodetected MIME:
    • audio/* -> <audio>
    • video/* -> <video>
  • For a given template:
    • page.tmpl -> eagerly fetch media
    • inlinepage.tmpl -> fetch just enough to display durations
  • Only for HTML5 sites, or also okay for XHTML?
  • Does this work well enough in enough browsers, or do we need a JavaScript player to fill in some gaps?

iTunes fancy podcasting

  • iTunes-specific tags appear to be RSS-only
    • Can we always include them in RSS feeds, or would that break some feed readers?
    • Is it even valid to include them in Atom feeds? If so, do Atom podcasts look any better in podcatchers?
    • Avoid adding a third kind of feed (itunesrss), or options to the existing rss and atom feeds, unless we have to.
  • Notable tags for feeds:
    • itunes:subtitle
    • itunes:author
    • itunes:summary (same as description)
    • itunes:owner (includes itunes:name and itunes:email)
    • itunes:image href=''
    • itunes:publisher
    • itunes:category text='' (can contain subcategories)
    • itunes:keywords
  • Notable tags for entries:
    • itunes:duration
      • Audio::TagLib might be fastest, if present and applicable
      • ffprobe is reasonably fast
      • mediainfo is way slower
      • Cache computed durations as pagestate
  • Podcast Feed Best Practice from the gPodder folks

Fancy podcast aggregating

  • Write tests comparing a fancy podcast (HTML and feeds) against the same podcast aggregated and republished, then make them pass via changes to aggregatepost.impl and aggregate.

Other ideas

  • Optionally specify the enclosure's:
    • MIME type, in case File::MimeInfo guesses wrong.
    • Duration, in case ffprobe guesses wrong.
  • Optionally specify enclosures outside the wiki:
    • Some people don't want to store big unchanging files in the VCS.
    • Other people like podcasting found media.
    • We'd have to download the file just to compute some metadata about it, and then somehow not frequently re-download it.
  • Configurably generate additional subscription links (such as iTunes) alongside the RSS/Atom ones in inline.
  • Support Apple's "enhanced podcasts" (if they're still relevant).