Well, 99% might be free, but the two you and ayup are running might be 
covering a much larger portion of hub users than 1%. To be honest, I don't 
see why this can't be an easily configurable option. (At the moment it's 
not really, you need to mess around with lease times and disable some code 
etc). Anyway, I don't care much for overly "smart" specs, just smart tools 
that can be actually used, so..

Cheers

On Friday, July 6, 2012 12:45:55 AM UTC+1, Julien wrote:
>
> 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
>>>>
>>>
>>>
>

Reply via email to