link rel=”feed-playlist”? Hehe.

But mostly, I see this as being something that replaces a chunk of the “buttons” on my site with one clickable button

ah yes, this would be it from Bloglines:

http://www.bloglines.com/export

which dumps out what I think you’d want.

Usually OPML is used for wholesale import/export of your subscriptions, whereas autodiscovery headers tend to be used to provide a choice.

Not that OPML couldn’t be used this way, too, but I do have to admit I don’t like OPML much. But hey, if it solves this problem cleanly, use what works.

The key is to have a well-known-extension and a mime type, so that both lame tools and Proper ones can do the right thing. (The extension can’t be OPML of course, because it is the verb, but I don’t care what syntax is used as long as it has a human readable label…) Oh, and that extension should replace XML on the candy buttons - because the word XML has “always” been wrong, in that it made about much sense as saying “ASCII” or “UTF-8″ there - but it did make the value of candy-like buttons really really clear, and it deserves credit for that…

FSS will do, I don’t see it in my local (aggressively updated debian) mime.types at least — there’s some artistic value in having it be “.feed” instead though…

Did you have to install a browser plugin the last time you clicked on the URL to a streaming station to make it startup in WinAmp or iTunes? This should be just like that.

Funny thing about this idea, though: after I mentioned Atom being able to do mime-type handling, with a link rel=”start” included in the feed, I looked at the current version of the format spec, and it seems to not do that, but instead has a link to a separate introspection file, which is basically an Atom playlist.

A browser plugin - who’d install that?

The aggregator installer.

The only trouble I can imagine with the plugin idea is if different aggregators all wanted to install their own plugin. A cooperative approach to the problem wouldn’t cause this to happen though.

The need to invent something new when we already have all the building blocks in place, is why we have 4+ versions of RSS.

I put Joe’s thoughts together in a proposal for RSS that would compliment Joe’s proposal for Atom and bring glee to the world.
http://www.kbcafe.com/rss/?guid=20050114133321

Assuming I have a browser (such as IE), and a URL such as http://www.example.com, the browser will do a default GET on the URL with a MIME type of text/html. Since there is no path, the server typically returns a home page as some prespecified page or by redirection.

To find the feed playlist, the browser could do a default GET on the URL with an accept MIME type of “application/atom+xml” (which is already registered). The browser does not need to know the name of the file or its extension - it just needs to know the server and the MIME type.

The file returned by a default GET with an accept type of application/atom+xml would be the “feed list” for the site. These are really the “atom endpoints” and is nothing more than an Atom feed with links pointing to the feeds and services on the site.

With autodiscovery, you give your aggregator the human-readable entry point ot a page and the aggregator uses various methods to find the feed.

With a “playlist” or feed:// or MIME types, you’ve already done the discovery work for the aggregator. You’re looking at the page, mouse hovering over a link to the feed, and you want to click on it, hoping it’ll do the right thing.

So, really, you wouldn’t ever need to autodiscover a “playlist”. If you want autodiscovery, put the playlist contents in the HTML head tag.

Leslie “0xDECAFBAD” Orchard writes: But, in the comment above, Phil [ringnalda] 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…