This weblog entry is going out in an RSS feed with this value:
Aggregators that support the element should check it no more than once every 90 minutes.
I meant to comment on the public mailing list about this, but TTL actually means the opposite of what you infer. TTL is the maximum, not minimum amount of time that a network should cache the data before the data is discarded and refetched. It's an old IP protocol thing. An aggregator that doesn't respect TTL would be one that isn't fetching the feed every 90 minutes.
Ugh! You gotta be kidding me. It's a "you better come back here in x minutes or you're in trouble mister?" Man did I misread that one around 100 times.
Heh. BottomFeeder uses ttl in the way you misread it, Rogers.
James, I'm not saying anybody is doing anything wrong here. If you are using TTL to schedule fetching every 90 minutes, then whether you implement before 90 minutes or after 90 minutes is minutia. The fact that BottomFeeder is even looking at TTL is better than ignoring it.
When I rewrote some of my programs for RSS 2.0, I added the TTL feature -- misreading/assuming that the RSS version of TTL was like the DNS version and represented the number of *seconds* until the next update. At one site that only updated once a day I figured I'd save bandwidth and instruct RSS readers not to check back until tomorrow, so I set TTL to 86,400 -- or 10 years -- causing much confusion as to why some aggregators never updated. Sadly, sites that follow TTL religiously, like Yahoo!360, cannot be persuaded to reload the feed. The moral of the story is that, um, RSS works a little differently than DNS.
Ugh...and I did my math wrong anyways...TTL for RSS is minutes, so it's two months, not ten years. Still, an awful long time for a feed to look stale.
I see nothing in this conversation that would cause me to modify feedparser's documentation of the ttl element.