Introduce stream_ttl #222
Introduce stream_ttl #222
Conversation
TusharR-google
changed the title
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. |
|
|
||
| > OPTIONAL. The lifetime of a PUSH stream in seconds, after which the Transmitter MAY either pause or disable the stream if it has not received any Receiver-initiated communication in that duration. | ||
| If the Transmitter decides to update the stream, it MUST send a Stream Updated Event to the Receiver as described in {{status}}. | ||
| If the Receiver calls any endpoint in the Event Stream Management API ({{management}}), the Transmitter must refresh the TTL of that particular stream. |
There was a problem hiding this comment.
We might want to be explicit that contact from the receiver does not automatically move the stream out of a paused/disabled state caused by a TTL timeout.
There was a problem hiding this comment.
Should we leave it up to the transmitter? It might complicate the spec if paused/disabled states were treated differently based on whether they were caused by a TTL timeout (Tx not allowed to automatically change the state), vs other causes like Rx requesting the pause (Tx allowed to do whatever).
| @@ -601,6 +618,13 @@ default_subjects | |||
| to be transmitted. The Receiver MAY remove subjects added this way via the | |||
| `remove_subject_endpoint`. | |||
|
|
|||
| stream_ttl | |||
|
|
|||
| > OPTIONAL. The lifetime of a stream in seconds, after which the Transmitter MAY either pause or disable the stream if it has not received any Receiver-initiated communication in that duration. | |||
There was a problem hiding this comment.
"Receiver initiated" needs to be clarified, IMO. Does it differ for poll and push streams? Is the appropriate response code from the receiver to a push from a Tx sufficient?
There was a problem hiding this comment.
Clarified the definition of "receiver-initiated" communication.
| @@ -601,6 +618,13 @@ default_subjects | |||
| to be transmitted. The Receiver MAY remove subjects added this way via the | |||
| `remove_subject_endpoint`. | |||
|
|
|||
| stream_ttl | |||
There was a problem hiding this comment.
can we make it stream_ttl_seconds? will save people working with the api a documentation lookup
There was a problem hiding this comment.
Most of the other names in the this/similar spec do not seem to use a suffix, regardless of units. E.g. min_verification_interval
So we could keep it as stream_ttl for consistency.
FragLegs
added
the
v1Final
| @@ -85,6 +91,17 @@ normative: | |||
| target: https://tools.ietf.org/html/rfc6749#section-4.4 | |||
| title: The OAuth 2.0 Authorization Framework - Client Credentials Grant | |||
|
|
|||
| EXPIRES_IN: | |||
There was a problem hiding this comment.
you don't need to describe an RFC. You can just add its number and the kramdown tool will do the rest.
| @@ -929,6 +946,19 @@ description | |||
| This is useful in multi-stream systems to identify the stream for human actors. The | |||
| transmitter MAY truncate the string beyond an allowed max length. | |||
|
|
|||
| stream_ttl | |||
|
|
|||
| > **Transmitter-Supplied**, OPTIONAL. The refreshable lifetime of the stream in seconds, after which the Transmitter MAY either pause or disable the stream if it has not received any Receiver-initiated communication (defined below) in that duration. The syntax is the same as that of {{EXPIRES_IN}}. | |||
There was a problem hiding this comment.
You might want to expand the acronym "TTL" somewhere in the description. You say it precisely in the first sentence, but you just don't say what "TTL" stands for. It'll help clarify the name even though most folks will know what it is.
|
|
||
| > **Transmitter-Supplied**, OPTIONAL. The refreshable lifetime of the stream in seconds, after which the Transmitter MAY either pause or disable the stream if it has not received any Receiver-initiated communication (defined below) in that duration. The syntax is the same as that of {{EXPIRES_IN}}. | ||
| > | ||
| > For PUSH streams, the Transmitter MUST refresh the TTL whenever: |
There was a problem hiding this comment.
Might be better to write this as: "For streams created with the PUSH {{RFC8935}} delivery method..."
| @@ -929,6 +946,19 @@ description | |||
| This is useful in multi-stream systems to identify the stream for human actors. The | |||
| transmitter MAY truncate the string beyond an allowed max length. | |||
|
|
|||
| stream_ttl | |||
|
|
|||
| > **Transmitter-Supplied**, OPTIONAL. The refreshable lifetime of the stream in seconds, after which the Transmitter MAY either pause or disable the stream if it has not received any Receiver-initiated communication (defined below) in that duration. The syntax is the same as that of {{EXPIRES_IN}}. | |||
There was a problem hiding this comment.
Is the right behavior "pause or disable", or just "delete"?
#211