Dave Winer has proposed a solution to the problem of proliferating "click-here-to-subscribe" buttons for every aggregator in existence. In a comment to an entry I wrote a while back on Dave's proposal, Boris Mann asks why the Syndication Subscription Service isn't the solution. In another entry Tim Bray points to the Atom solution to this problem. These three all solve the problem, but in different ways. Here's my analysis of how they work:
A Big OPML Repository in the Sky
We might call Dave's proposal the "big OPML repository in the sky." Dave proposes a server, based on code in the public domain, that houses your OPML file. When you click the "subscribe" button the URL of the feed your subscribing to is added to your OPML directory of feeds and your feedreader knows to check that first everytime it goes out to check for new news.
One thing I like about this approach is that its pretty simple, requiring changes from the feedreader builders, but not the users or RSS hosters. I also see other uses for technology like this in building directories for RESTful Web services. The big downside, in many people's minds, is the centralization that it imposes by gathering together all the OPML files in one place. I can understand that.
Building Custom Subscriber Pages, One User at a Time
The Syndication Subscription Service (SSS) builds a custom page for you with an icon for every feedreader it knows about. You click on the "subscribe" button and then select your feedreader from the list.
SSS has the advantage that its in place now and works. I don't like the two step process, however. I also think its less generalizable for other kinds of WS directory applications. SSS is decentralized in the sense that it doesn't require users to store their OPML files there, but its still one place and, as far as I know, the source code isn't public domain.
Client-Side Linking
The Atom solution proposed by Tim relies entirely on client-side linking. RSS feeds are identified on the page with a URL and the server is configured to return them with a media-type of application/rss+xml. A properly configured browser then hands off the URL to the feedreader.
The nice thing about Tim's solution is that there's no server to interpret the data, this solution is completely decentralized. The downside is that browsers have to be configured to interpret the media-type correctly and RSS servers have to send the right media-type. This solution, as a WS directory most closely resembles WSIL and that's not all bad.
Combining Models
At the risk of complicating this well beyond what is needed, I've been wondering how we could take Dave's suggestion (which I like in principal) and generalize and decentralize it a bit. My idea is to create a hierarchical system not unlike DNS where people can choose to store their own OPML and organizations can delegate the storing of OPML to sub organizations. I know, its more complicated, but as a RESTful was of doing WS directories, it would be extremely flexible and decentralized. That's more interesting to me than just solving the subscribe button problem.
