Back in the early days of this millennium, I was working on a thing called “Kinda Smart Syndication” (KSS –was code-named “kickitch” on the iCite net) that was an API for blog data, that could respond to requests with data in formats like RSS, RDF, JSON, etc. The “supporting multiple formats” part was the really easy part, but there were other ways that was being handled (that are still in use), e.g., linking to multiple feeds on the page and via the LINK elements in the head portion of the HTML.

I mention all of that because it’s kinda similar, if you think about it:

* multiple formats that might be used / preferred by different clients

* the relative ease of generating and serving multiple formats

* the user experience scenarios between multiple links to multiple feeds (unclear / confusing) vs a single reference to a standard API

* the obligation it places on clients to be “smarter” relative to links (e.g., requiring Javascript vs just plain HTML; or browsers get smarter)

With RSS, this has been resolved more by browsers getting smarter–on some sites with RSS, the RSS links don’t even appear on the page, but are handled in the head LINK tag via browser generated UI (e.g., the RSS button that appears in the location bar in Safari).

Personally, in general, I think the API model is better because the user experience is better understood in terms of interactions. In other words, the real solution to any issue like this is better enabling an interaction, and changing formats (or, standardizing on a single format) are almost irrelevant to that.

But, philosophically, browser software isn’t super oriented towards interactions on this level. The browsers’ built-in Feed interactions only came about after years of people putting gigantic links to each RSS feed on everything.

But, in this case, it’s maybe safer to think about this in Javascript and/or Flash -specific terms, since almost all of the audio players are using JS or Flash.