Allow for inifinite lease_seconds times

[GoogleCodeExporter]

SUMMARY:

> Hmm. The spec makes this optional when (un)subscribing, but mandatory when
> validating a subscription. What if the hub doesn't want to implement an
> auto-lease-expiry? That is, either it can't be bothered dealing with leases
> at all, or it wants on a case-by-case basis to let a lease last for infinity
> seconds. I can think of three possibilities:
>
> let hub.lease_seconds be the empty-string on validation calls to the
> callback (alternatively, let it be "0", and let "0" mean "unbounded"); or
> let hub.lease_seconds be omitted on validation calls to the callback, to be
> interpreted as "unbounded"; or
> the status quo.

RELEVANT SECTION:  6.2

COMMENT/REQUEST:

Yes I think the infinity case makes sense. It seems like 0 or -1 could be a
fine value for the lease_seconds to mean unbounded. I don't think this
should be optional on the subscription verification request though. It
should be clear how long your subscription will last. But knowing it's
infinity sounds good to me.

Otherwise, we could make the parameter also required during the unsubscribe
case. In this case, the lease_seconds parameter could mean how long the
current subscription has before it expires?

Original issue reported on code.google.com by bslatkin on 14 Jul 2009 at 8:07

[GoogleCodeExporter]

Just want to chime in on the ticket that I'd prefer to punt on how default 
behavior
is handled ... my preference short-term is to let hub implementation decide how
defaults work. As in, I'd prefer my hub to default to infinite, where others 
may want
to default to 30 days or something. 

Others may even want to make it explicitly required, but until we figure out an
agreeable default value, we leave it open to implementation. (This is not 
ideal, just
a way to be pragmatic about learning what the default should be before people 
start
expecting it to be one thing by it being encoded in the spec)

Original comment by progr...@gmail.com on 18 Jul 2009 at 10:13

[GoogleCodeExporter]

I think it should be easy for Subscribers to request infinite, without keeping 
much/any state or background lease renewals on their side.

I think the onus is on the hub to re-check subscribers and see if they're 
either/both 
1) still alive/reachable, 2) still wanting the subscription.

This is consistent with our philosophy of pushing all complexity towards the 
hub, and 
keeping the edges simple.  I personally was annoyed when I wrote my subscriber, 
having to deal with lease renewal logic.

Original comment by b...@fitzpat.com on 20 Jul 2009 at 5:58

[GoogleCodeExporter]

Original comment by bslatkin on 27 Aug 2009 at 8:15

• Added labels: spec0.2

[GoogleCodeExporter]

Addressed in 0.2

Original comment by bslatkin on 2 Sep 2009 at 1:21

• Changed state: Fixed