On Thu, Mar 11, 2010 at 11:07 AM, Brett Slatkin <[email protected]> wrote: > I worry that the alternative to these details is having subscribers > that are overly paranoid and send subscription requests to hubs every > hour or so just to be sure they're always subscribed.
Even if hubs did what you described (rolling refresh attempts) I think you'd still have "overly paranoid" folks sending in subscribe requests again. If they look at this and say: Wow, if I returned an error I might not get updates for another six hours! I should just send in a new subscription request right now so that it gets turned back on right away (assuming the errors have been fixed)! Also (and maybe this was implied and I didn't pick up on it) what happens during the time between the first error happens (the 502 from nginx in your example) and the scheduled refresh attempts? Is the callback temporarily suspended until the next scheduled refresh attempt? Or does it continue to send pings hoping that it will start working again at some point? Another approach would be error thresholds. For instance I could keep a counter for the number of failed delivery attempts. Once that hits a certain limit (say 5 as an example) then the callback is suspended. Depending on the conditions this could be worse or better than refresh attempts. For feeds that only have new posts once a day it's pretty good, since that gives the callback lots of time (one day) in between pings to catch and fix a problem and 5 days before it gets suspended. For feeds that have new posts once an hour that window is shrinks quite a bit. But that also means we stop trying to bombard them with new updates pretty quickly. -- Joseph Scott [email protected] http://josephscott.org/
