We’re about to see an explosion in podcast syndication. Not only are the ranks of podcasters growing rapidly, but a number of sites and services that want to aggregate podcasts have appeared with many more to follow shortly. There are already at least three syndication channels through which I’d like to publish IT Conversations content.
The problem is that I’m releasing way too many programs to manually upload files and enter metadata into three or more web sites. It could easily take a few hours every day, and as the number of syndication deals, it just gets worse.
So I think we — the podcasting community — have a chance to create a standard for the syndication of podcasts. I don’t think RSS is the best way to do this because the large aggregators aren’t going to want to be polling all the producers all day long. Better would be something like OPML and the ipodder.org directory for which a publisher creates and XML file and then pings the recipient, asking that the file be retrieved. Either that or a REST-style HTTP POST to accomplish the same thing. Or XML-RPC?
How to pull this off? Perhaps the best starting point would be to try and get the aggregators/syndicators together. If you’re in that category and would like to participate in the discussion, send me a note (firstname.lastname@example.org). Let’s just see who replies for now.
4 thoughts on “Not-So-Simple Syndication”
I’m not sure I understand why that’s better, Doug. I think OPML would be a fine mechanism, but don’t get why it’s better than RSS for this purpose.
RSS can (and does) use the ping model, and could certainly be adapted for this purpose, and you’ll still have the meta-data problem with OPML, won’t you? I think that that problem could also be solved by an RSS namespace built around pod- and video-casting – obviously that’s been suggested before, but since there’s been (as yet) little commercial benefit to it, no one’s bought in to any one namespace. With the right carrot and the right players on both sides a well thought-out RSS namespace dealing with the multimedia meta-data would work just as well, wouldn’t it?
I’m not saying your solution’s not fine, and maybe I’m missing something, but I don’t understand why it’s better.
I agree with kinrowan. If you’re going to be pinging, you might as well stick with RSS. The whole pinging + RSS system seems to be working pretty well. There doesn’t seem to be a need to develop something new (whether REST or XML-RPC) currently.
I think the efficiency Doug’s pointing to is this: The edge pings the center when there’s new programming, rather than having the aggregator crawling for new data constantly. It reduces traffic for all involved, albeit only a little bit for any individual podcaster.
Does that make it worthwhile? Maybe, especially if the aggregator is adding a lot of subscription management value, which I think is what has to happen in order for any syndication channel to stand apart from the system that connects podcasters directly to their audience through RSS.
Doesn’t the edge-center thing work equally well for RSS and OPML? I’m all down with that – my blog pings about a dozen sites – even ones that do their own crawl, like Feedster. I still don’t get why OPML makes for a better mousetrap here.
I definitely think the aggregator thing has some potential, especially for non-podcast geeks who don’t want to think about feeds and RSS/OPML – they just want their content. And I think we all hope those folks are coming to podcasting. I’m thinking something like Bloglines’ recommendation page, ecept that it gets delivered to you automatically so you can take a listen – then the aggie makes it really easy to subscribe to that too. Much more efficient for the average Joe than the way we’re doing it now, but OPML still doesn’t make it better or worse that I can see.
What am I missing?