On Wed, Sep 22, 2010 at 5:13 PM, Doug Kaye <[email protected]> wrote: > Thanks, Brett. That's the kind of stuff that isn't in the spec (yet?). > Much appreciated.
I'm sorry I'm not being clear. The spec says: http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#rfc.section.6.2.1 "Hubs MAY make the hub.lease_seconds equal to the period the subscriber passed in their subscription request but MAY change the value depending on the hub's policies. (<--- this is the part you care about) To sustain a temporary subscription, the subscriber MUST re-request the subscription on the hub before hub.lease_seconds seconds has elapsed. For permanent subscriptions with no hub.lease_seconds value specified, the behavior is different as described in the section on automatic subscription refreshing (Automatic Subscription Refreshing). " And then: http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.3.html#autorefresh "Before a subscription expires (i.e., before hub.lease_seconds elapses), Hubs MUST recheck with subscribers to see if a continued subscription is desired. Hubs do this by sending the subscriber a verification request (Hub Verifies Intent of the Subscriber) with hub.mode equal to subscribe. This request MUST match the original verification request sent to the subscriber (but with a new hub.challenge). The response codes returned by the subscriber MUST be interpreted the same way as during a subscriber-initiated verification flow. However, this refresh request MUST behave like an initial subscription request; this means that if an auto-refresh response from the subscriber constantly returns an error, the hub MUST give up on the subscription verification action altogether and remove the subscription. 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. This behavior provides the best of both worlds: maximum simplicity of the subscriber through infinitely-long subscriptions, but still garbage collectable subscriptions for hub hygiene. " Effectively, *all* subscriptions are permanent as long your callback continues to response correctly to the subscription verification callback that comes through periodically before your lease expires. What I've done is change it so the maximum period of that double-check is 10 days regardless of what the user requests, and 5 days if the user specifies nothing (i.e., a permanent subscription). -Brett > On Wed, Sep 22, 2010 at 5:11 PM, Brett Slatkin <[email protected]> wrote: >> On Wed, Sep 22, 2010 at 4:52 PM, Doug Kaye <[email protected]> wrote: >>> Thanks, Brett. So when you wrote "I've also narrowed the max >>> expiration window to 10 days and set the default to 5 days (instead of >>> 30 days)" that's saying that your hub will automatically delete >>> subscriptions after 5 days (default) or 10 days (max)? If we request 0 >>> days, does that imply the default (5 days) or the max (10)? >>> >>> Or were you talking about something completely different? :-) >> >> Ah okay. So that means the hub.lease_period will default to 5 days for >> subscriptions, meaning you'll get a call back within those 5 days to >> confirm you still want your subscription before you're unsubscribed. >> And the 10 days number means even if you request a lease period of >> infinity, I'll still recheck you want your subscription every 10 days >> just to be sure. >> >
