Podcasting mechanics

After I posted yesterday's audio interview, Paul Schaeflein wrote to point out that I ought to be using RSS 2.0 enclosures in my feed so that enclosure-aware aggregators can download media objects.

The reason I hadn't done so, until now, is that I've been focusing more on screencasts than on podcasts. It seems unlikely that anybody would want to play back a screencast on a mobile device. And because you can progressively download screencasts and experience them in more-or-less real time, there's not a huge incentive to cache them.

Clearly, though, a 55-minute audio interview like the one I posted yesterday qualifies as a podcast -- the sort of thing you might want to listen to on a portable player, away from your computer, while taking a walk or riding in your car or exercising at the gym. So it was a good opportunity to scope out the emerging infrastructure of podcasting.

The enclosure tag is quite straightforward. Here's mine from yesterday:

<enclosure url="http://jonudell.net/udell/gems/CunninghamGreenfield.mp3"
  length="19570944" type="audio/mpeg" />

It would be easy for any blog publishing tool to emit this code. In my case, I'm publishing with Radio UserLand, which has a set of preferences related to consuming and publishing enclosures. Here's the relevant preference for publishing enclosures:

Check this box if you want to be able to add enclosures to your own output channels. (A new field will appear on the desktop website home page.)
That field looks like this:
Enclosure:
If an item has an associated media object, you enter its URL here. Obviously, you must have first uploaded the file. Your publishing tool can then figure out the length of the file, and add the enclosure tag to the <item> element in your feed.

So far, so good. Next, I wanted to see my podcast show up at audio.weblogs.com, a service that tracks recently changed feeds that contain media objects, just as the original weblogs.com tracks all recently-changed blogs. In both cases, it's up to the blog publishing tool to "ping" the service to signal that an update has occurred.

The how-to for audio.weblogs.com tells developers of blog publishing tools how to ping audio.weblogs.com using XML-RPC. It also points you to a form available to users whose publishing tools don't automatically issue the ping.

On my first try, I entered the URL of my RSS feed into the ping form, and it was accepted, but my item didn't appear on the audio.weblogs.com list -- though it did appear at audio.weblogs.com/changes.xml. Looking through that list, I noticed a mixture of feed URLs and blog homepage URLs, and wondered if maybe I should have used my homepage URL instead of my feed URL. Again the ping was accepted, again no joy.

So I checked with Dave Winer. It turns out that you should, in fact, use your feed URL. Primary blog URLs are accepted, but probably shouldn't be -- they'll have no effect in this context.

What was wrong with my feed, then? Dave pointed me to the debugger where I found out the hard way what is spelled out in the checklist: the channel-level <language> element, though optional in RSS 2.0, is required for this application. So I added that to my feed, and voila:

1. Heartland News at Noon 11/22/04 7:37 AM 2.3MB XML
2. Heartland News at 5pm 11/22/04 7:37 AM 2.8MB XML
3. Software factories: a conversation with ... 7:37 AM 18.7MB XML

I really enjoyed yesterday's interview, and plan to do more of them, so it's good to have gotten this machinery sorted out. Should I also use enclosures for screencasts? Even though it's probably a marginal use case for the enclosure tag, I suppose there's no reason not to. So I'll plan on that too, and we'll see how it goes.


Former URL: http://weblog.infoworld.com/udell/2004/11/23.html#a1120