A few days ago I wrote a piece about how to reboot RSS. A lot of people read the piece, and asked me to expand on the ideas from a technological point of view, which I'm glad to do. 

To begin, let's review the architecture of RSS.  

Here are the basic concepts. 

1. Feeds. They come from lots of places. Blogs have feeds. News organizations have them. Sources for news organizations have them. Even Twitter provides its content in the form of feeds. I have a feed from my stock broker, and from Netflix, recommending new releases I might want to watch. Amazon offers me deals. I subscribe to a feed from the NOAA that tells me about the hurricanes, as the news becomes available. This is the same feed that the Times and Reuters and AP watch. I get news from a huge number of tech blogs. From English-language news sources in Europe and Asia. I get radio programs, links to new software downloads. I even follow a few Twitter users whose updates I don't want to miss. I subscribe to feeds about the place I live now, and places I used to live. And of course feeds from friends I want to keep up with. All of this and much more comes to me through feeds. 

2. Feed items. Each item in a feed has several bits of data: A title, link, description, publication date, identifier. Not all are always present. And there is other data that is less common but also appears: An enclosure, categories, a pointer to the source of the item (if it was republished). 

3. Feed engine. It reads a collection of feeds periodically, and from that collection produces a stream of new content. There are lots of them. There's one embedded in every feed reader. I've written several.  

4. Subscriptions. Each user has a collection of subscriptions, which can be edited. You can subscribe to a feed, which is most commonly done when you're viewing a website and decide to add it to your collection. You can decide you no longer wish to see items from a feed, or unsubscribe. This usually happens when you're reading feeds.  

5. User interface. There are lots of ways to read feeds. There's the hierarchic approach favored by Google Reader and NetNewsWire (examples). There's the River of News approach that I like. You can have feed content emailed to you, or SMS'd, or read it in Twitter or Facebook or Friendfeed. There are many other user interfaces for feed reading. 

Feeds and engines, and the tools that generate feeds, are independent of each other, and this is a good thing. You have your choice in every category. But there is one place where having choice makes RSS weaker and harder to use, and that's in the act of subscribing to a feed.  

Here's the scenario. I'm reading a news article and realize this is the seventh time in the last two days that I've been at this site, and I really like the way they cover the news. A thought forms in my head: "I want to subscribe." This is where the user experience can get confusing. It's different for everyone. If the site provided a link to subscribe in your favorite reader, it's easy. But if they didn't, and if you haven't installed a bookmarklet, you're in for some copying and pasting, navigating and waiting. And you'll lose your place. Most of the time you decide not to bother. And the use of reader-specific links reduces the number of choices, and this is where the stagnation in the RSS market came from. This, the act of subscribing, is the act that we have to make more fluid, easier, more satisfying, faster. 

It's important to say that I am not proposing any changes in the architecture of RSS. I am however, proposing that some new software be built, with the aim of making RSS easier to use, more reliable, and to create a more diverse marketplace with lots of opportunity. 

And that's where I'm going to stop for today. There are more pieces coming, if there's an interest.