This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Return of the killer RSS Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

This story seems to recycle every few months in a "the sky is falling, the sky is falling!" sort of fashion:

Already, aggregators have swamped some sites, slowing Web servers and eating up expensive bandwidth, according to bloggers and other Web publishers. The end may be near, unless something changes soon, said Gary Lawrence Murphy, whose Linux blog, TeledyN, has been overloaded.

There's an answer to this, and it's called conditional-get. Browsers implement it, and it's not hard to implement in an aggregator - I added it to BottomFeeder over a year ago. I'd be curious to know which aggregators don't implement this, and why. This does lead me into another area along the same bandwidth related lines though:

The Atom guys have been (and still are) seriously considering the addition of binary data blocks to Atom feeds (music, images, video, etc). That's a nice sounding idea until you combine it with the way HTTP works. Say I add a 3 MB video file to my feed. Smart aggregators that use conditional-get will only get that data once - until the feed is updated again, that is. The problem is, there's no way to get a partial document using HTTP. That means that large attachments to a feed will be fetched every time a feed is changed. If you have a rarely updated feed, that may not be a problem. If it's a blog that's updated regularly, it's a problem.

The funny thing is, this exact problem is addressed by RSS Enclosures - by providing a reference to that sort of data, and allowing the client aggregator to grab the data in any way it chooses - some kind of background process, a simple link for the user to follow, whatever. That's the right way to do this, IMHO - the proposed Atom support is just a bad, bad idea in the context of HTTP.