[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-solutions for blogs.msdn.com: (was RSS consumes too much bandwidth)


Another non-solution is to put a "hold-off" parameter in the feed header.
Aggregators should delay for this hold off time before polling again. If the
server starts becoming overloaded, it simply increases the hold-off time
to decrease its loading. This is a feed centric solution and not a transport
solution. This should automatically throttle back the loading - that is if
aggregators don't ignore it ;-)

Brett Lindsley, Motorola Labs



Sam Ruby wrote:


Bill de hÓra wrote:


Mark Nottingham wrote:

At any rate, there are a number of things we (and the market) can do to mitigate this before we call RSS/Atom "broken."


I don't get the sense that people will think RSS/Atom is the problem. My sense is that they'll think HTTP polling is the problem. All RSS/Atom does here is turn the volume on the Curse Of Popularity up to 11. Even in this thread, I'm not observing solutions that target Atom - they're all HTTP optimizations, bar one.


This thread started by somebody noticing that Robert Scoble (a big fan of RSS) saying "RSS is broken". [1] Robert may not understand the bits and bytes as well as some of the people here, but he is far more technical then most of the intended audience.

So far we have listed a lot of what I will call non solutions:

  1) Get ISPs worldwide to buy Inktomi software
  2) Use ETAG/Last-modified (they already are)
  3) Use compression (they already are)
  4) Don't post so often
  5) Put HTTP Expires info in the body (they'll ignore it there too)
  5) Shave a byte here or there on a header.

One thing that would be very helpful here is if we could get some hard data from MSDN on request rates, types of requests, user agents, and the like.

- Sam Ruby

[1] http://radio.weblogs.com/0001011/2004/09/08.html#a8195