Feed “Playlists” versus feed:// URLs

l.m.orchard — Thu, 13 Jan 2005 16:21:54 +0000

Then, this is the point in the cycle where I remember that the real lesson of the past to learn from is from MP3 playlists, where a link needs to pass one or more URLs to a helper app, and that what we really need is to not to link to our feeds, but to a file that links to them.

Source: kalsey.com: Handling RSS in the browser, comment by Phil Ringnalda

You know, back when feed autodiscovery was first whipped up, I thought that it was great. Today, there’s lots of support for it, and it’s even found its way into browsers. But, well, it still doesn’t solve the problem of people clicking on those darn candy-like buttons.

So, then some folks came up with a new feed:// protocol for feed URLs. It seems there’s just too much gone wrong with MIME types and the like. When I first heard of feed://, I thought it was a weird and ugly hack, but I never piped up because I was too busy at the time, didn’t know much of the details, and was too busy to be bothered to catch up. Besides, other people were grousing about it already. And, later, I saw that a slew of aggregators were supporting it, so I figured it must not have been that bad, although I still thought it was odd to kludge around a new URL “protocol” just to pass a feed URL to an aggregator.

But, in the comment above, Phil makes a suggestion that seems ideal to me. Don’t link to feeds directly, don’t use a funky protocol, link to a “playlist” of feeds. URLs linking to MP3 playlists (ie. the informally specified M3U and PLS files) seem to get tossed and handled just fine by your preferred media player. I don’t even know how the MIME-type situation is handled with M3U or PLS links, but it seems to work just fine nonetheless.

And, wasn’t there this Really Simple Discovery thing published a long time ago? Point a weblog management tool at your site, it looks for rsd.xml, and it gets all the funky URLs it needs for web services from there?

What if we circled back around with autodiscovery and published a file like this:

Name it something like feeds.fss, link your candy-like buttons to it, and register applications to handle that extension. Give it a MIME-type, and handle that too. Sounds just like M3U and PLS files, to me. Someone tell me why this is a dumb idea.

Update: Just to clarify, before anyone thinks I’m just railing against Dave Winer personally–I made a comment below about not liking OPML. Well, I don’t, at least not for this particular purpose. But, my preferences aside, it’s undeniable that most aggregators support OPML import/export in one form or another, so the above example could probably be expressed as OPML with all the same data.

Just one thing, though (and this is part of why I don’t like OPML for this): On my machine, OPML outlines and files with an “.opml” extension open with OmniOutliner. OPML means “outline” to me, not just “list of feed URLs”. I don’t want URLs ending in “.opml” to open in an aggregator. Can we at least use a different extension and/or MIME type?

0xDECAFBAD » 2005 » January » 13

Feed “Playlists” versus feed:// URLs