What I don’t like about RSS
Really Simple Syndication (RSS, and a similar protocol, Atom) has been touted for several years as the way to keep track of many things: blog posts and comments, wiki edits, news headlines, even email messages and Twitter feeds. Nevertheless, email remains the de facto notification mechanism for most people and applications. I use RSS quite regularly to manage my blog reading, but I’m not very satisfied with it. Here’s why:
RSS is a pull medium
Any time I want to use an RSS reader, I need to ask my RSS reader to collect (pull) the RSS summary from each of the “feeds” (typically blogs) that I subscribe to. This works reasonably well for content that changes relatively slowly like many blogs, but works less well for headlines and especially Twitter. There is no mechanism for notifying me when something new shows up; I need to poll for it.
Lack of multi-device integration
I read blogs from at least three devices: my home machine, my work laptop, and my iPod Touch. I also read my home email from all of those places. The difference is that when I read an email message, all three places show the message as having been read. Not so with RSS. The devices don’t have a way of communicating with each other, so each time I change devices everything looks unread. Subscriptions are similarly disaggregated; I have to subscribe to each feed on each device. I’d rather, when I find a new blog (or something) worth reading, to be able to add it to all devices at once.
Poor reading organization
Rather than organizing the information by feed, I’d rather have a more flexible way of prioritizing the information. This is more of a client software problem than a protocol problem, but it’s still a reason I don’t like RSS as much as I might. I’d like it if my RSS reader organized the information it presents to me by subject (perhaps using keywords or tags to do so), or according to a more complex sorting algorithm that either I could specify or it would learn from my reading behavior.
Older information is lost
RSS feeds typically syndicate only relatively items, and are often limited to only the most recent N articles, where N is typically 20 or so. If N increases, the size of the feed increases proportionally, as does the overhead for the reader which has to match the current feed against its stored database to see what has already been read. However, lower values of N fail if the reader doesn’t regularly retrieve the feed. One currently has to expect that articles may be lost when you go on vacation, and that limits RSS to non-critical tasks.
Unless we want to continue to use email as a notification mechanism for everything, it would be useful to have a syndication mechanism that doesn’t suffer from the limitations of RSS (or Atom). A new mechanism could be designed that is more tailored to this purpose than email, and can be designed from the start to avoid the many ways that email is abused. For example, Mark Cuban recently talked about the use of WebHooks and PubSubHubbub to overcome the pull limitations of RSS and similar protocols. These and other (push) protocols have the potential to make the use of the Internet a much more responsive, event-driven experience.
Altmode 
Personally, I favour a hybrid mechanism, in which a server does the Atom/RSS polling on your behalf, and stores the results in folders that are presented to your client through IMAP. That gives you the best of both, and solves all the issues you mention.
Of course, it requires that you have a server that will “subscribe” for you (read: poll; I dislike referring to RSS as “subscription” because of the “pull” aspect of it), but that’s pretty much necessary for any method that collects things when you’re away.
On the other hand, if you really want a “push” subscription, well… that’s just email, isn’t it?
Good summary of my thinking, Barry. Are you aware of any servers that do this, i.e., do Atom/RSS polling and present it to you via IMAP? That would just leave some of the organizational pieces — one might want to prioritize certain notifications (and classes of notifications) above others.
I’m still troubled by the amount of needless polling that this implies, though.
Yes, email is a push mechanism, but it’s not the only push mechanism. It might turn out to be the answer, though, much as it has for meeting invitations (calendaring).
Yes: the server I wrote.
Actually, I’m in the process, as time permits, of rewriting my server in Java. That’ll make it (1) easier to maintain, and (2) mine, rather than just a research prototype of IBM’s, which will never be used anywhere else. It mixes and matches lots of Internet standards to allow collecting mailing-list subscriptions and RSS feeds, and presenting them through NNTP as well as IMAP. For the re-write, I’ll probably implement RSS on the other end, too, in case anyone should want to use an RSS reader to read email (or maybe not).
But you’re right: polling is almost always the wrong thing to do. Which is why I think the right approach is to use email subscriptions, along with a filter on the email server to shift things into separate folders. I follow 30 or 40 IETF mailing lists that way — I subscribe to all of them, but they all just go into folders that I look at when I want to. I’m never missing anything because I went away, and I can use the email server’s search capabilities to find things and to do the prioritization.
The only thing I don’t have that RSS readers give me is automatically deleting messages after I’ve read them. But, then, that’s not always what I want to do anyway, so….
Check out Google Reader (http://www.google.com/reader/). As long as you don’t mind Google knowing what RSS you like to read, it should definitely help solve the lack of multi-device integration, and it certainly helps me with organization, since I can put multiple tags onto a single feed.
Jeremy, thanks for the pointer to Google Reader. While I was aware of it, I hadn’t actually kicked the tires. Privacy concerns aside, while it does help with the multi-device integration and somewhat with the organization (since you can have a chronologically-mixed view), it lacks something I have with RSS: the ability to download the feeds and view them offline. Especially with my iPod Touch, I like to look at feeds when I’m on a bus, waiting in line, or other places where I might not have a live Internet connection.
But I see a solution for that — I can get an RSS feed from Google Reader and download that. Somehow this seems to be going in circles.
But I’m one of those people who prefers to get his mail from an IMAP server somewhere other than Google. While my choice of reading material wouldn’t raise any eyebrows, I would still prefer not to share it.
What you REALLY want is Google Wave (wave.google.com) which uses XMPP for bidirectional, real time synchronization of syndicated feeds. Instant update, instant response. Check out the demo.
I have seen the demo, yes. What hasn’t been demonstrated is the way Google Wave scales. What happens when the notifications are for new articles for The New York Times or Slashdot?
But yes, XMPP is a push protocol worth considering for notifications. I’m not sure all the bells and whistles of Google Wave are required for this application, however.