Martin, The only thing is that, at least for now, 99% of the hubs are actually free hubs... so there is no customer paying, and when a subscriber callback dies, there is no way for the hub to know for sure :) So, we'll stick with expirations and re-confirmation in the spec for now!
Julien On Thu, Jul 5, 2012 at 1:13 PM, Martin B. <[email protected]> wrote: > Hi Julien, > > Well, in general I disagree with this confirmation process - basically > regardless of what the service is, when a client subscribes to it, you > don't keep on asking him "do you still want this?" as long as he pays > (where applicable) and as long as his subscription callback is accepting > data. > > So basically I understand that the GAE hub doesn't really support the > feature by default - as you said, I'm sure I'll find a way to make it > support it ;) > > Cheers, > Martin > > > On Thursday, July 5, 2012 6:08:37 PM UTC+1, Julien wrote: >> >> Hey Martin, >> >> Generally, you actually want to have some kind of deadline to the >> subscription on the hub and not stuck with it for your whole life. >> Basically, feeds (like any other web resource) may go down, and/or >> subscribers may also disappear... you want to be able to check that and >> stop notification to these. >> >> The new 0.4 spec will probably insist on the fact that subscriptions need >> to stay 'clean' for both the subscribers and the hub who some kind of >> garbage collection mechanism. >> >> As for the GAE hub implementation, I haven't looked at it in a long time, >> but I'm sure you can can find ways to dp what you want. >> >> Thanks, >> Julien >> >> >> On Thu, Jul 5, 2012 at 5:05 AM, Martin B. <[email protected]> wrote: >> >>> Hi guys, >>> >>> I'm looking at the 0.3 version of the hub and it seems that the >>> expiration feature is required for all subscriptions. However, the 0.3 spec >>> draft seems to suggest that hubs may decide if subscriptions will expire or >>> not? Basically, I'm looking to build a hub where subscriptions don't expire >>> and don't need to be reconfirmed - is it simply a matter of removing the >>> cron jobs for subscription reconfirmation/cleanup or will the latter also >>> result in unsubscribed subscriptions not being cleaned up (not sure if >>> those are deleted straight away, or when subscription_cleanup is called). >>> >>> If there is no clean way to set this up, I'll hack around, was just >>> wondering if I'm missing some easy switch somewhere or something. >>> >>> Cheers, >>> Martin >>> >> >>
