When I looked at this I considered subscription requests to a hub to mean essentially the following:
"Please send me updates until I give you a reason to stop" The first obvious reason for stopping is to send the hub an unsubscribe request. The second reason I'd say (as has been talked about on another thread on this list) is for the subscriber's callback URL to start returning an error status. From the point of view of the hub I'd consider anything that is >= 300 an error and reason to suspend the callback URL. This discussion so far has focused on the hub's responsibilities, but there are related issues on the callback end as well. If the callback URL suddenly starts returning 403 Forbidden during some 30 minute interval (could be anything pulled that out of the air) then I think it's up to that client to send new subscription requests, knowing that the hub might have suspended it's subscriptions. On Wed, Mar 10, 2010 at 4:05 PM, Brett Slatkin <[email protected]> wrote: > 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. -- Joseph Scott [email protected] http://josephscott.org/
