So, you want to set up an RSS feed for a podcast? Ah, young grasshopper, there is much data to munge and so little code to munge it with … at least code that you can live with.
I recently had the need to create an RSS feed for a podcast and discovered that, while you can do a lot of the heavy lifting yourself, it is much easier to use a tool for the purpose.
Before we start let me just make it clear what an RSS feed is: It is a file-based list of descriptions of, and meta data about, content items (HTML blog content or audio or video files) that is intended to be updated at some regular interval. There are a number of RSS formats and versions but the most common by far is RSS 2.0.
If you are just starting out in the podcast biz you could resort to creating a really simple starter RSS 2.0 feed using a service like Podcast RSS Feed Generator. As they say on the cooking shows, "here's one I made earlier":
<?xml version="1.0"?> <rss version="2.0"> <channel> <title>Test</title> <link>http://test.com/</link> <description>Testing feed generator</description> <language>en-us</language> <copyright>(c) Test.com, 2009.</copyright> <lastBuildDate>Tue, 2 Jun 2009 01:47:34 GMT</lastBuildDate> <generator>tdscripts.com Podcast Generator</generator> <webMaster>admin@test.com</webMaster> <ttl>1</ttl> <item> <title>Enclosure 1</title> <description>A test enclosure</description> <pubDate>Tue, 2 Jun 2009 01:47:34 GMT</pubDate> <enclosure url="http://test.com/content/test1.mp3" length="147,657" type="audio/mpeg"/> </item> </channel> </rss>
This generator (rating, 2 out of 5) only produces the text of a very simple feed and skips a lot of the hardcore features and options available in RSS 2.0.
Despite its limitations the Podcast RSS Feed Generator provides a pretty good demo of the basics. You'll notice first of all that RSS Version 2.0 is XML 1.0 compliant and if you want your feed to work correctly you'll have to make sure you write correct XML.
A feed is defined within the <channel></channel> tags and includes the name of the channel (<title></title>), the uniform resource identifier (URI) of the channel (<link></link>) along with a description, the language used, publisher's copyright, and other obvious meta-information.
I'm sure you can figure out the intent of all of the other tags in the example above except maybe "<ttl>", that's the "time to live", the number of minutes that a client-side cached version is valid for.
The TTL value used in the example defines that, if the feed was read more than one minute ago, the client must assume that any locally cached copy of that channel's feed they might have will be obsolete. A more appropriate value might be, say, "120" or "1440".
There are a few other tags that along with <ttl></ttl> are called "syndication hints". Hints "suggest" to feed clients when and what frequency of access are appropriate for a feed. The other tags are (<skiphours><hour></hour> … </skiphours> and <skipdays><day></day> … </skipdays>) which are meant to tell clients not to bother accessing the feed at those hours and on those days. Of course, this doesn't mean that the clients will obey the constraints and, in fact, many clients, by default, poll the feeds they monitor every hour no matter what the feed suggests.