Introduce inactivity_timeout #222
Conversation
traib-google
changed the title
appsdesh
left a comment
appsdesh
left a comment
There was a problem hiding this comment.
Push and Pull are delivery mechanisms defined outside the SSF spec. We should not introduce new aspects specifically targeting a single delivery mechanism in the SSF spec
I agree. Can we just make this |
Thanks! The same concept can be applied to PULL streams too, let me reword this as simply stream_tll. |
FragLegs
added
the
v1Final
Resolve latest comments
inactivity_ttl is more descriptive than just stream_ttl
Co-authored-by: Shayne Miel (he/him) <miel.shayne@gmail.com>
Since the comments have been resolved in the PR, I'm going to "dismiss" this review. @appsdesh please comment if you think this still needs addressing. |
tulshi
dismissed
appsdesh’s stale review
The comments from this review were resolved by the author.
Co-authored-by: Shayne Miel (he/him) <miel.shayne@gmail.com>
Co-authored-by: Shayne Miel (he/him) <miel.shayne@gmail.com>
FragLegs
left a comment
FragLegs
left a comment
There was a problem hiding this comment.
This looks great! Thanks for all the diligence getting it tuned up so well.
|
|
||
| inactivity_timeout | ||
|
|
||
| > **Transmitter-Supplied**, OPTIONAL. The refreshable inactivity timeout of the stream in seconds. After the timeout duration passes with no eligible activity from the Receiver, as defined below, the Transmitter MAY either pause, disable, or delete the stream. The syntax is the same as that of `expires_in` from Section A.14 of {{RFC6749}}. |
There was a problem hiding this comment.
After the timeout duration passes with no eligible activity from the Receiver
We should consider successful event delivery to the receiver as an eligible activity and possibly clarify it. We don't always need Rx making API calls, correct?
There was a problem hiding this comment.
For PUSH streams that's not enough, at least from a security/privacy perspective - receiver endpoints are more likely to be open, the only way to verify that the receiver exists and still has the right auth/access is for it to call the transmitter endpoints (oauth-protected in most cases).
For PULL, polling is sufficient.
6 participants
#211