Thanks! This is basically what I'd expected, but it's good to have it confirmed. ;) From a subscriber perspective, that seems pretty easy to implement - just accept refreshes from the hub whenever, and if a lease runs out, then resubscribe. So, awesome. As far as clarifying the spec: * In section 6.1, it lists lease_seconds as "Number of seconds for which the subscriber would like to have the subscription active." This implies that the subscription will not be active (ie, expired) after that time, so this should really be rephrased to specify that it's the maximum number of seconds they want to wait for a refresh. * Similar change in section 6.2, with lease_seconds in the hub verification. * Section 6.2.1 implies that leases where the subscriber specifies the lease_seconds are temporary, and the hub won't try to refresh those; is that still accurate? If not, it should be changed. If it is, section 6.3 should be clarified, since right now it seems to say that before *any* lease expires hubs *must* try to refresh. * Right now it's unspecified whether notifications may be delivered after a lease expires. On second thought, this is fine - it seems pretty reasonable to allow a hub to deliver notifications after the lease expires, but not to necessarily guarantee it, for example if they're queued for delivery.
Thinking more about temporary leases now. Are there any use cases for them? If not, then it'd be simpler not to have them in the spec, and just assume that the hub will always try to refresh a subscription when it expires. Any use cases I can think of are handled better by explicitly unsubscribing anyway. --Ravi On Fri, Oct 16, 2009 at 11:32 PM, Brett Slatkin <[email protected]> wrote: > > Hi Ravi, > > Sorry for the delay in responding. > > 2009/10/11 Ravi Pinjala <[email protected]>: > > > > I'm trying to test that my aggregator works with automatic subscription > > refreshing properly, but after setting a really short (10 minutes) lease > > interval, I don't get any kind of request from the hub to refresh the > > subscription. Also, I'm still getting notifications, so it seems that > > the lease lasts longer than what's returned in lease_seconds by the hub. > > > > So, my question is, how strictly is lease_seconds interpreted by the > > hub? is it intended to mean that the subscription will end at that time, > > or that it won't end until some unspecified point after that time? And > > if it's the latter, how long should a client wait before giving up on > > the automatic refreshing, and trying to resubscribe? > > Great questions. > > Right now the reference hub implementation only clears old leases once > per day. I'm soon going to be changing this to be much more fine > grained (probably every 60 seconds). That explains the behavior you > are likely seeing. > > Practically, Hubs SHOULD make a best-effort attempt to clean up your > subscription within the lease time-frame. They indicate the effective > lease_seconds value in the subscriber verification request that they > SHOULD honor, but it's not a "MUST" in the spec. > > In terms of intent and the spec, subscribers should assume that if > they have not received a subscription auto-refresh by the end of the > lease seconds that something is broken and they should go and > resubscribe to the feed. > > Is that in line with your expectations? Is there any way the spec > could make this more clear? Thanks for all the feedback, > > -Brett >
