Looking again at fancying up podcasts for iTunes.

diff --git a/doc/todo/fancypodcast.mdwn b/doc/todo/fancypodcast.mdwn
index 128017021fb55eb900dc577779ddbc2f7a964ea7..e26893e4838ec78fd0d880b532a578c61a390308 100644 (file)
--- a/doc/todo/fancypodcast.mdwn
+++ b/doc/todo/fancypodcast.mdwn
@@ -30,8 +30,12 @@ Episode enclosure  |(./)      |(./)       |(./)        |(./)
 
 * [iTunes-specific tags](https://www.apple.com/itunes/podcasts/specs.html)
   appear to be RSS-only
 
 * [iTunes-specific tags](https://www.apple.com/itunes/podcasts/specs.html)
   appear to be RSS-only

-    * If they work in Atom, teach `inline` to optionally iTunesify RSS/Atom.
-    * Else, add `itunes` as a third kind of feed (RSS plus more stuff).
+    * 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`
 * Notable tags for feeds:
     * `itunes:subtitle`
     * `itunes:author`


@@ -47,6 +51,9 @@ Episode enclosure  |(./)      |(./)       |(./)        |(./)
         * [ffprobe](http://ffmpeg.org/ffprobe.html) is reasonably fast
         * [mediainfo](http://mediainfo.sourceforge.net/) is way slower
         * Cache computed durations as pagestate
         * [ffprobe](http://ffmpeg.org/ffprobe.html) is reasonably fast
         * [mediainfo](http://mediainfo.sourceforge.net/) is way slower
         * Cache computed durations as pagestate

+* [Podcast Feed Best
+  Practice](https://github.com/gpodder/podcast-feed-best-practice/blob/master/podcast-feed-best-practice.md)
+  from the gPodder folks

 
 ### Fancy podcast aggregating
 
 
 ### Fancy podcast aggregating