If you use Google Reader as your RSS client you’ve probably noticed that it sometimes takes hours or even a day before it “sees” updates to your RSS feeds. Here’s Google’s official response:
http://www.google.com/support/reader/bin/answer.py?answer=70642&topic=12011
Which explains why updates to lesser known feeds (like friends’ blogs) come so late. There’s some discussion on the web that this is because they do not want popular sites getting hammered with requests, but shouldn’t the update schedule then be opposite? Feeds with fewer subscribers could handle more frequent requests. Maybe Google is caching the popular feeds then sending the posts from the cache. Hmm…. someone needs to make a bittorrent + RSS mash-up. In the meantime, I’m sorry friends but I may not see your blog updates until the day after.
Todd Stadler | 25-Apr-08 at 8:23 am | Permalink
Yeah, I don’t know. Google should be fetching one copy of the feed fairly frequently, and then passing this on to as many subscribers as Reader has for that feed. If that happened, the fact that a feed had a billion subscribers shouldn’t affect whether the feed’s server got hammered, right?
But that only really works if there is a finite number of canonical feeds for a site. The problem comes in when you have comment feeds for every blog entry, or customizable feeds with parameters, or feeds per account (like on Twitter). Then Google’s attempt to frequently check for updates for each feed (even if it only grabs one copy, caches it, and passes it on to Reader users) could easily take down a site. Maybe these per-account/customizable/parameterized feeds are what Google means by “less popular” feeds, as opposed to the one-feed-per-site ones?
Also, I think a friend of mine at Rice built just what you want: FeedTree (Google it). The problem with it, as with all P2P services, is that you need a body of users for it to work.
How about an XMPP+RSS combination? I’ll call it … RSSXMPP!