Makes sense to me, but yours is a question for Mozilla.

It took a lot of trial and error to figure out how to handle the situation. And a lot of sites still do itms:// for RSS when there’s an enclosure. But there was an advantage in that it was possible to extend the infrastructure by adding a link in the page.

Bundling codecs with browsers is akin to bundling fonts with browsers. For type, the pragmatic, effective approach is enhancing the APIs to OS and Web accessible fonts via CSS @font-face, enabling the potential of rich typography on the Web.

Open the API and the OS system and browser plug-in developers will compete to fill the codec implementation opportunities. Meanwhile publishers presentation code is unaffected; Publishers may add media encodings as the market innovates and ultimately self-corrects.

FWIW, Songbird has done a lot of heavy lifting to bring the LGPL’d GStreamer framework + wrappers for Windows Media and Quicktime media cores to the Mozilla stack. =)

Rob

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.