search

ankurpiyush26 / pubsubhubbub

Automatically exported from code.google.com/p/pubsubhubbub
Other
1 stars 0 forks source link

Make the use of lease_seconds in verification requests more clear for auto-refreshing #109

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
SUMMARY:

The lease_seconds parameter in verification requests should be used by 
subscribers to figure out when they should expect the next hub check-in. 
If subscribers don't get a check in by that time, they should probably re-
request the subscription to ensure they're still connected.

RELEVANT SECTION:  6.3

COMMENT/REQUEST:

From Ravi:

> One thing that's sort of been bothering me. If the hub for some reason 
loses
> a subscription, or if the subscriber loses connectivity for an extended
> period and the hub drops the subscription, how does the subscriber 
know that
> the subscription's been lost? In the worst case, the subscriber would wait
> until lease_seconds runs out, and then see that the hub didn't auto-
refresh
> the subscription and resubscribe. However, this could take a while; the
> reference hub uses a month for lease_seconds, IIRC, and it was 
mentioned in
> another thread that wordpress uses 10 years (!!!). So, this can't really be
> depended on.
> The options I see for a subscriber are:
> 1) Pessimistically resubscribe whenever there aren't any updates for a
> while. "For a while" is pretty subjective, though, and depends on the feed 
-
> this will end up creating a lot of unnecessary sub requests. Plus, it
> requires a lot of guesswork and some state tracking on the part of the
> subscriber.
> 1a) Even more pessimistically, resubscribe periodically. This seems kind 
of
> wasteful, but it's also the solution that's least subject to hub failures.
> 1b) Just set a really short (I'm thinking ~1 day) hub.lease_seconds value 
in
> the request. This works as long as the hub respects the lease_seconds 
value,
> but it's not required to. 
> 2) Continue polling feeds, and resubscribe if updates happen that aren't
> sent over PuSH. This would work, and seems like it would give the best 
of
> both worlds, but it's a disappointing solution, because PuSH was 
supposed to
> get rid of polling. 
> 3) Assume that the hub never ever fails. This is great, until a hub fails.

Original issue reported on code.google.com by bslatkin on 10 Mar 2010 at 11:07

GoogleCodeExporter commented 9 years ago 
My list response:

I'm in agreement with this.  Guidance would be a good thing.  30 - 60 days seems
reasonable, to me, but I could be pushed as low as 14.  Any lower than that just
causes thrashing, and any greater people start to question the usefulness.

Original comment by jrossi...@gmail.com on 10 Mar 2010 at 11:10