Hacker News Reader

You should already be able to implement this using the If-Modified-Since HTTP header. The server only needs to send you back articles in the RSS feed that have been added after that date. The If-Modified-Since value is meant to come from the previous responses Last-Modified (not a timestamp you make up), so that side-steps timezone issues.

I think that still requires a change to both the server and the reader - although at least not a new standard.

> Still, exceptionally low cost compared to running pretty much any website's massive CSS and JS files.

My blog has both RSS and browser readers, but the bandwidth is dominated by the RSS feed. Since the RSS file has no images (just HTML pointing to the images), I think it's more likely that for my Wordpress blog the CSS/JS overhead is just not that much (as opposed to the alternative hypothesis that I have many many times more RSS readers who never end up downloading the images).

Or you have way more users via rss than through their browser. This could be a good thing as it results in less bandwidth than if they all hit you directly through browser.

My parenthetical comment raised this hypothesis and rejected it with a reason. So you should address that reason if you want to disagree.

>the bandwidth is dominated by the RSS feed

Exceptionally low cost per hit, as opposed to overall bandwidth. Overall bandwidth will probably fair off worse as you say due to the polling nature of RSS. I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth.

Also in general, I would be tempted to make an RSS feed more minimalist in terms of content and markup. It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately).

>I think it's more likely that for my Wordpress blog the CSS/JS overhead is just not that much

Also, bandwidth is just one resource - potentially each call to a page is a database read, whereas your RSS feed should be static (not sure about the WordPress implementation, but I would hope for static caching with something that doesn't change for long periods of time). I've seen WordPress database lockups with modest amounts of traffic (again, most of the time this could have been easily statically cached - but doesn't appear to be by default).

>> the bandwidth is dominated by the RSS feed

> Exceptionally low cost per hit, as opposed to overall bandwidth.

I don't understand. I'm telling you that my RSS file literally dominates my bandwidth usage in GB.

> I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth.

Yah! Agreed.

> It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately).

No, I want people to be able to read it offline. I'm not trying to monetize anything.

> Also, bandwidth is just one resource - potentially each call to a page is a database read

I have a simple website. The bandwidth is the dominant cost.

>> I think in general RSS readers could do a better job of fetching heads and checking whether or not there is a change worth fetching, that would save a tonne of bandwidth.

> Yah! Agreed.

You could also reduce the number of `<item>`s you keep in rotation to a more manageable number.

>> It should just be a short `<description>` and a link to the main article (which would still allow you to potentially monetize your content or gauge interest more accurately).

> No, I want people to be able to read it offline. I'm not trying to monetize anything.

It should still be much more lightweight than it's HTML counterpart. Should be almost nothing to it, next to no markup, no styling, no scripts and a highly compressible piece of data.

I don't understand how you're racking up massive bandwidth. Can you put some numbers to it:

* Bandwidth usage for RSS

* Bandwidth usage for webpage

* Hits to RSS

* Hits to webpage

* Links for both

That’d impose a cost on the server, remembering an ID map. Instead make the client send back a value given by the server last time.

I think that's what they meant by "an ID [...] of the last request"

That's something both RSS consumers and produces should already support, but don't always, called an E-Tag, a standard part of the HTTP standard. However, the E-Tag is all-or-nothing; either it matches, and the entire request is essentially aborted, or it doesn't match, and the entire file is served up.

Passing "the ID of the last piece of content I saw" would allow the server to return just the updated stuff, or abort early like an E-Tag. However, counterintuitively, as is often the way in computer science, I'm not sure it would be that big a win to be able to return partial content. The vast bulk of the win on most blogs will just be the ability to abort at all, provided just fine by E-Tags.

I would say that if your site is getting hammered by HTTP requests for your RSS, do double-check that you've got E-Tags set up and working correctly. It is in the best interests of the big scrapers to support that properly, as they are paying for that bandwidth too. RSS aggregators don't have to get too large before this becomes a top-priority feature request. Unless the feed is literally changing on roughly the same frequency as it is scanned, it shouldn't be the dominant factor in your bandwidth bill.

Couldn't the feed server use the Last-Modified HTTP header to note the most recent feed item sent to the client?

It's at least a 95% solution; I don't know about 100%, in the face of the ability to delete items and modify timestamps after they've been posted.