Stream: fhircast-github
Topic: fhircast-docs / Issue #319 Re-subscription needs clarific...
Github Notifications (FHIRcast) (Jul 01 2020 at 21:36):
matthiaswilder opened Issue #319:
Currently the spec suggests that re-subscription is supported by including the
hub.channel.endpointparameter in a subscription request. However, it makes no mention of re-subscription in the Subscription Denial/Confirmation sections. In those sections the language is written as if the subscriber will _always_ need to connect to a websocket before receiving a confirmation/denial, but in re-subscription the subscriber has presumably already connected.The obvious solution here is that the confirmation/denial is sent automatically, since the connection is already open. But I have had one person suggest that this implies another behavior where the subscriber reconnects to the websocket on every re-subscription.
I think that language calling out permutations of the subscription for re-subscription should probably be more explicit and less inferred.
Github Notifications (FHIRcast) (Jul 01 2020 at 21:36):
matthiaswilder edited Issue #319:
Currently the spec suggests that re-subscription is supported by including the
hub.channel.endpointparameter in a subscription request. However, it makes no mention of re-subscription in the Subscription Denial/Confirmation sections. In those sections the language is written as if the subscriber will _always_ need to connect to a websocket before receiving a confirmation/denial, but in re-subscription the subscriber has presumably already connected.The obvious solution here is that the confirmation/denial is sent automatically, since the connection is already open. But I have had at least one person suggest that this implies another behavior where the subscriber reconnects to the websocket on every re-subscription.
I think that language calling out permutations of the subscription for re-subscription should probably be more explicit and less inferred.
Github Notifications (FHIRcast) (Jul 01 2020 at 21:36):
matthiaswilder edited Issue #319:
Currently the spec suggests that re-subscription is supported by including the
hub.channel.endpointparameter in a subscription request. However, it makes no mention of re-subscription in the Subscription Denial/Confirmation sections. In those sections the language is written as if the subscriber will _always_ need to connect to a websocket before receiving a confirmation/denial, but in re-subscription the subscriber has presumably already connected.The obvious solution to me here is that the confirmation/denial is sent automatically, since the connection is already open. But I have had at least one person suggest that this implies another behavior where the subscriber reconnects to the websocket on every re-subscription.
I think that language calling out permutations of the subscription for re-subscription should probably be more explicit and less inferred.
Last updated: Apr 12 2022 at 19:14 UTC
