vrijdag 10 september 2004

On Monday the 13th, my hosting provider will upgrade one of their MySQL servers. It will be the one on which the data for the comments and trackback system is hosted, so if you're using the system, please note that it cannot be used on this time:
  • monday-tuesday night, 1 AM - 4 AM (CET)
Also, the web server for this blog might be unavailable for a short time during the upgrade.

A quote from Paolo Valdemarin on the RSS/bandwith problem as described by Robert Scoble:

"A very simple feature that aggregators could have would be letting users decide how frequently they want to poll every feed they subscribe to. While some feeds might require hourly scanning, other could be scanned every 2, 4, 6, 12 or 24 hours.

Extending this philosophy, a preference could be set also at feed level, indicating how frequently a feed should be polled (why keep polling it if it doesn't update?). "

An idea very much like this I wrote down yesterday on my Dutch blog. Another small idea I had was to let the aggregator calculate the update frequency of a feed, every time it's updated. This way, a feed would be read almost as often as it updates, and no bandwith would be wasted.

Or an aggregator could have some scheduling, like: I go to work at 8 AM, so I want it to scan at 7, so I can read some feeds before I leave. When I return from work, I want to read more, so it should already have scanned again by that time. That's two scans on one day. Now, let's say I want to read some more after dinner, so I let the aggregator scan again all (or some, see Paolo's quote) feeds during dinner time. And before I go to sleep I want to read some, so one hour before my usual bed time, it scans again.

That's 4 scans, instead of 24.

Of course there are lots of variations to the ideas like these. Bottom line is, I think: aggregators should have configuring options. Users should be able to control the behaviour of their aggregator, to fit their own needs as well as the feed providers needs.