Automatic subscription refreshing is meant to address this case in general:
http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#autorefresh This part is specifically for what you're all talking about: "In the case of permanent subscriptions (with no hub.lease_seconds specified in the original request), the hub.lease_seconds value supplied by the hub in the verification request to the subscriber SHOULD represent how many seconds until the hub expects it will next initiate automatic subscription refreshing to ensure that the subscriber is still interested in the topic." It's up to the hub to configure the reliability window they want to have for their subscribers. It's up to subscribers to read the lease-seconds off the verification request and use it to know when to double-check with the hub. In the reference hub I believe this period is 10 days. It seems like we could provide more guidance in the spec for what an intermediate refresh interval should be as a best practice. On Wed, Mar 10, 2010 at 2:33 PM, Matthew Terenzio <[email protected]> wrote: > I always thought the indefinite lease was a bad idea but was scared to say > it. I'm scared to say it now because I know people will throw tomatoes at > me. > > RSSCloud has a 24 hour lease and the feed has an update interval to clue you > in on when it it might be appropriate to do a sanity check. Did I expect an > update on these feeds in the last three hours? Yes? Well if I don't hear > from them in the next three hours I'll do a check. Or the interval could be > 48 hours or a week for slow moving feeds. > > With such a system, you could actually create dynamic rules on both ends to > accommodate feeds that change their behavior over time. > > I don't think there is a perfect solution to this except writing such good > hubs that the issue melts away. > > Before you throw tomatoes, I also agree with what Jay and Bob say. Just > pointing out an alternative method to address an issue that will always be > there. > > Throw tomatoes. : ) > > >
