Robert Scoble's done some calculations that illustrate why RSS is becoming a bandwidth nightmare for large sites.
Aggregators constantly pinging the RSS feed for updates clearly doesn't scale. This certainly isn't news, but MSDN pulling their full-text feeds is the first high profile example.
The problem can be eased by reducing aggregators' polling frequency - once every couple of hours, or even once a day - but surely that's a band-aid? Scale up the (currently tiny) number of RSS readers a few thousand times and the stickiness of RSS means you've still got a problem, even polling once a day.
Besides which, limiting polling to once per day destroys a large chunk of the appeal of RSS: I want to know whenever stavros updates, and I want to know NOW, dammit.
So what's the solution? A push technology is never going to provide what RSS does - we're immediately back in the world of email and spam and filtering and... ugh. And any pull technology is always going to poll for changes. So the solution must lie in limiting the bandwidth required by the poll.
I have no wish to descend into the depths of the RSS/RDF/Atom/Semantic Web debates, but the solution lies there, in the specification. RSS providers need a way to tell aggregators "go away, there's nothing to see here for another 12 hours". And it needs to happen in less than a couple of Kb.
Recent Comments