I've opened this issue to clarify the role of lease_seconds in this way: http://code.google.com/p/pubsubhubbub/issues/detail?id=109
On Wed, Mar 10, 2010 at 3:05 PM, Brett Slatkin <[email protected]> wrote: > 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. : ) >> >> >> >
