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 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.

Here's Phil's comment:

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. That indirection also has the added benefit of keeping random spiders (like Google) that don't actually understand them from ever seeing them: if you don't know how to parse application/feedlist+xml, you'll never see the URLs for the feeds themselves.

Now I didn't really get what Phil was saying in the post I linked to below but the above system seems to have everything. Leslie goes on to spell it out in detail:

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

<feeds xmlns="http://www.decafbad.com/2005/01/feeds">
    <link rel="alternate" type="application/rss+xml" title="Full RSS" 
         href="http://www.decafbad.com/index.rdf" />
    <link rel="alternate" type="application/atom+xml" title="Full Atom" 
         href="http://www.decafbad.com/atom.xml" />
    <link rel="alternate" type="application/rss+xml" title="Blog-only RSS" 
         href="http://www.decafbad.com/blog/index.rdf" />
    <link rel="alternate" type="application/atom+xml" title="Blog-only Atom" 
         href="http://www.decafbad.com/blog/atom.xml" />
    <link rel="alternate" type="application/rss+xml" title="Links-only RSS" 
         href="http://www.decafbad.com/links/index.rdf" />
    <link rel="alternate" type="application/atom+xml" title="Links-only Atom" 
         href="http://www.decafbad.com/links/atom.xml" />
</feeds>

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.

Feed playlists. Name it something like feeds.fss, 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.

Now what does this remind me off ... oh yes: OPML! Why create another XML application when we already have one that's perfectly suited to this application?

Here's all that needs to be done:

• Everyone creates an OPML wrapper for their feeds
• The put an orange FEED link on their webpage pointing the OPML file. If you want to post the feeds of someone else's site, just link to their OPML file (and you no longer need to worry if their feed structure evolves)
• Optionally, a special extension and or mime type could be used for these files to indicate
• The ".opml" extension is registered in the browser to send a message to their aggregator. Aggregators should allow the user to selectively choose feeds from the OPML file. Sparks! and Jäger already allow you to do this.

Hmmm ... that's pretty simple and builds beautifully on the technology we already have!

I'm noticing that already that there's comments that are anti-OPML (which historically have been hard to dissassociate from anti-You Know Whoism) but given the amazing amount of traction that OPML has picked up in the last six months, why put ourselves through all the misery of the Atom/RSS schism again? OPML works, is simple and our aggregators have the code to handle it.