*od-o-matic

Welcome to project *od-o-matic. I'm in the process of setting up, but lemme clue you in—this project is being established for the purpose of making one or two tools that make life better for podcasters.

One of the bases upon which I've started this project is an effort to provide to the independent *odcaster (podcaster) some tools that would otherwise need to come from a third-party site. (For example, the functionalities of subtool and the XSLT stylesheets are both inspired by the offerings of FeedBurner—see this example, the feed for the Accident Hash podcast.) There's a significant reason for this: Podcasting is a system with at least one built-in system point of failure (SPOF), the availability of the RSS document at the given feed URI. This is usually tolerable since the RSS and the show files are usually on the same server, so if the feed couldn't be downloaded, the show wouldn't be accessible anyway. Introducing third-party systems such as FeedBurner can be convenient, but pose a risk to the independence of a podcast. If your own site is up, but the third-party site that hosts your feed is down, your subscribers are needlessly in the dark. If the third-party site goes out of business, chokes too much for comfort, or simply changes its terms of service and you don't like the change, you'll suddenly be struck with a change in your feed URI, and it's difficult to get listeners savvy to your new feed.

Choosing a feed URI

The best way to keep your feed's URI in a fixed location (so you won't have to change it later) is to host it using a domain name you own. Ideally, you want a URI that is easy to read and understand on its own. Decent examples include:

Generally, it's probably a good idea to choose a simple, easy-to-read URI for the show's website, and then add "feed" (or something of the like) to the end to indicate the feed location.

mod_rewrite

Even if you're using a tool like WordPress to generate your podcast's RSS feed—or routing through a third party like FeedBurner, for that matter, that doesn't necessarily mean you're stuck with their feed URIs. On most Apache webservers, there's an interesting tool called mod_rewrite that can be used to return the contents of one URI when the user enters another.

Say you're using WordPress, and your feed's URI is something ugly like http://example.com/show/?feed=rss2 but you'd rather have http://example.com/show/feed. This is an easy trick, provided that

Anyway, getting that to work is as easy as going to the /show directory of your website and adding this stuff:

RewriteEngine on
RewriteRule ^feed$ /show/?feed=rss2 [L]

There's other stuff you might need to do for this to jibe with the rest of your site, but mod_rewrite is definitely useful in this regard.

Notice: If there's anything you don't understand about this stuff or the concept of regular expressions, you're better off asking a tech to do this for you.

Project: Subscription tool (subtool)

License: GNU GPL

This tool will be a simple PHP menu system which helps end users subscribe to your podcast by answering questions about their environment. If the user's podcatcher supports a one-click subscription mechanism, it will be employed; in any case, part of the goal is to provide a step-by-step for as many different podcatchers as possible.

If you'd like to contribute a tutorial for subscribing and updating podcasts in your podcatcher of choice, please send what you've got, but only if the documentation is available under a free license (since all this documentation is subject to editing, it had better be free!), and cite the source, even if you are the author. I'm looking for some fairly detailed, step-by-step, end-user-oriented instructions which speak in terms of an actual feed URI instead of using any sort of "e.g." or "for example" devices. (This is because, well, we're working with PHP, and a PHP script can fill in the blanks automatically instead of confusing novice users who are liable to try subscribing to http://example.net/podcast/feed.rss.) But don't worry if what you submit doesn't quite follow format; again, everything is subject to editing. Walkthroughs in non-English languages might also be handy.

This project is slightly underway; it's in CVS under the module name subtool.

Project: XSLT Stylesheets for RSS

License: GNU LGPL

Another nice FeedBurner service that really needs an independent equivalent is its ability to, in most modern browsers, turn an ordinary RSS feed into a human-readable XHTML document. If you've ever wondered how it does this, look no further than the second line of the source:

<?xml-stylesheet href="http://feeds.feedburner.com/~d/styles/rss2enclosuresfull.xsl" type="text/xsl" media="screen"?>

This document describes an XSL stylesheet. XSL (Extensible Stylesheet Language), and, in particular, its sub-technology XSLT (XSL Transformations), is most often used to convert XML documents into other XML documents, for example, RSS to XHTML. Current versions of Firefox, Mozilla, Netscape, and IE are able to apply XSL styles directly inside the browser. FeedBurner takes advantage of this by turning what would otherwise be a somewhat cryptic RSS feed document into a human-readable web page.

I'm currently learning what I'll need to know about XSLT to make this happen without FeedBurner's assistance.

Comments

If you've got anything to say, I'm listening.

Danx — Dro

SourceForge.net Logo