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. : )
>>
>>
>>
>

Reply via email to