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 >> > >
