Hacker News Reader

Comment by ankrgyl | Hacker News Reader

I don't think getting you to visit their site is the point of the switch. Twitter and FB are in a position where they have enough addicted users that they can get away with messing with standards. RSS is outdated and slow, and FB and Twitter want people to use their data in a more sensible way, via their flexible APIs.

It's trivial to build an APP that generates an RSS stream for an arbitrary twitter account with their API, and I'm sure someone will soon. But the point is that they are setting a new standard for what can be done streams of structured data, and hopefully more sites will move away from RSS into cool APIs.

Of course, for now at least, there's no standard to this kind of API, but I think that people will eventually figure out what works and converge to it (as is the case with OAuth).

View on HN

I hear people talk about how "RSS is so slow" all the time, but I still don't understand it. I see no failings or complaints about RSS. I get a headline and then I get an article. Are we talking speed between when content was generated and when it appears in an RSS feed? Honestly, I couldn't care less about that. I'll live if it takes fifteen minutes for an update to reach me. It's not like I'm getting a patient's live EKG readings via RSS.

As for yet another standardized API to replace it. As long as it provides the same functionality to all current services/devices that use RSS, that's fine with me. I would really prefer that it not be driven by Facebook and Twitter, however any more than I want Microsoft Office development teams driving the standardization of ODF.

If you read about FriendFeed's Simple Update Protocol (http://blog.friendfeed.com/2008/08/simple-update-protocol-fe...), you'll find some good arguments about why RSS slow. The crux of the problem is that to get any updates on a feed, you have to request and download the entire RSS feed (which is filled with summary text and is of nontrivial size).

Consider the case of a real-time news aggregator. A news source doesn't update very frequently (say once every 5 minutes), but you want to provide updates super fast (say within 30 seconds). That means on average you have to scrape the entire RSS feed 10 times for a single update. On the other hand, FB/Twitter APIs give you the flexibility to do things like "download items after this id," which hog much less bandwidth.

Looking at that article, the slowness doesn't come from having to download the entire RSS feed. As commenters there note, If-Modified-Since means you only need to download the feed when there are changes. So in your second paragraph, you have to ping the RSS feed 10 times, but you'd only need to download it once.

Rather, the slowness seems to come from the lack of an aggregation mechanism. If I want to follow 100 feeds (e.g. 100 Twitter users), I have to query each of those 100 feeds. Even though I can query them efficiently using If-Modified-Since, that's still slower than firing off one query to find out which of those 100 feeds have updates, and then querying only those which do.

Good point. The reason I didn't bring that up is that the comments suggest that if-modified-since isn't universally adopted by RSS publishers.

> Of course, for now at least, there's no standard to this kind of API, but I think that people will eventually figure out what works and converge to it (as is the case with OAuth).

Actually there is but twitter is not interested (for obvious reasons): http://ostatus.org/sites/default/files/ostatus-1.0-draft-2-s...

Reply on news.ycombinator.com