Stream: fhircast-github
Topic: docs / Issue #69 Close events don't contain context
Github Notifications (FHIRcast) (Feb 08 2019 at 15:56):
wmaethner opened Issue #69
The closing events currently don't have any context specified, but it seems useful to know the context of what specifically is being closed. This would be extremely useful in the case of unidirectional integration syncing. For example a subscribing app receives the notifications for an open study and puts that in focus. They are not implementing bi-directional syncing and the user then opens a different study in the subscribing application. The driving application then closes the original study. The current spec would dictate that the subscribing app close the current study or both studies, either of which I don't think is necessarily what we want. If they only close the in focus study (study B) then the original study is still open in the subscribing application even though it was closed in the driving application which seems clearly wrong. If they close both then that could annoy the user who wanted to keep in focus that manually opened study.
This has caused some issues with current integrations where some systems don't pay attention to the context of the close and will instead just close everything or the current thing which can cause some weird behavior.
Github Notifications (FHIRcast) (Feb 08 2019 at 16:25):
wmaethner assigned Issue #69(assigned to wmaethner)
The closing events currently don't have any context specified, but it seems useful to know the context of what specifically is being closed. This would be extremely useful in the case of unidirectional integration syncing. For example a subscribing app receives the notifications for an open study and puts that in focus. They are not implementing bi-directional syncing and the user then opens a different study in the subscribing application. The driving application then closes the original study. The current spec would dictate that the subscribing app close the current study or both studies, either of which I don't think is necessarily what we want. If they only close the in focus study (study B) then the original study is still open in the subscribing application even though it was closed in the driving application which seems clearly wrong. If they close both then that could annoy the user who wanted to keep in focus that manually opened study.
This has caused some issues with current integrations where some systems don't pay attention to the context of the close and will instead just close everything or the current thing which can cause some weird behavior.
Github Notifications (FHIRcast) (Feb 08 2019 at 16:25):
wmaethner unassigned Issue #69
The closing events currently don't have any context specified, but it seems useful to know the context of what specifically is being closed. This would be extremely useful in the case of unidirectional integration syncing. For example a subscribing app receives the notifications for an open study and puts that in focus. They are not implementing bi-directional syncing and the user then opens a different study in the subscribing application. The driving application then closes the original study. The current spec would dictate that the subscribing app close the current study or both studies, either of which I don't think is necessarily what we want. If they only close the in focus study (study B) then the original study is still open in the subscribing application even though it was closed in the driving application which seems clearly wrong. If they close both then that could annoy the user who wanted to keep in focus that manually opened study.
This has caused some issues with current integrations where some systems don't pay attention to the context of the close and will instead just close everything or the current thing which can cause some weird behavior.
Github Notifications (FHIRcast) (Feb 08 2019 at 16:26):
wmaethner assigned Issue #69(assigned to isaacvetter)
The closing events currently don't have any context specified, but it seems useful to know the context of what specifically is being closed. This would be extremely useful in the case of unidirectional integration syncing. For example a subscribing app receives the notifications for an open study and puts that in focus. They are not implementing bi-directional syncing and the user then opens a different study in the subscribing application. The driving application then closes the original study. The current spec would dictate that the subscribing app close the current study or both studies, either of which I don't think is necessarily what we want. If they only close the in focus study (study B) then the original study is still open in the subscribing application even though it was closed in the driving application which seems clearly wrong. If they close both then that could annoy the user who wanted to keep in focus that manually opened study.
This has caused some issues with current integrations where some systems don't pay attention to the context of the close and will instead just close everything or the current thing which can cause some weird behavior.
Github Notifications (FHIRcast) (Feb 08 2019 at 16:26):
wmaethner assigned Issue #69(assigned to isaacvetter)
The closing events currently don't have any context specified, but it seems useful to know the context of what specifically is being closed. This would be extremely useful in the case of unidirectional integration syncing. For example a subscribing app receives the notifications for an open study and puts that in focus. They are not implementing bi-directional syncing and the user then opens a different study in the subscribing application. The driving application then closes the original study. The current spec would dictate that the subscribing app close the current study or both studies, either of which I don't think is necessarily what we want. If they only close the in focus study (study B) then the original study is still open in the subscribing application even though it was closed in the driving application which seems clearly wrong. If they close both then that could annoy the user who wanted to keep in focus that manually opened study.
This has caused some issues with current integrations where some systems don't pay attention to the context of the close and will instead just close everything or the current thing which can cause some weird behavior.
Github Notifications (FHIRcast) (Feb 08 2019 at 16:26):
wmaethner assigned Issue #69(assigned to isaacvetter)
The closing events currently don't have any context specified, but it seems useful to know the context of what specifically is being closed. This would be extremely useful in the case of unidirectional integration syncing. For example a subscribing app receives the notifications for an open study and puts that in focus. They are not implementing bi-directional syncing and the user then opens a different study in the subscribing application. The driving application then closes the original study. The current spec would dictate that the subscribing app close the current study or both studies, either of which I don't think is necessarily what we want. If they only close the in focus study (study B) then the original study is still open in the subscribing application even though it was closed in the driving application which seems clearly wrong. If they close both then that could annoy the user who wanted to keep in focus that manually opened study.
This has caused some issues with current integrations where some systems don't pay attention to the context of the close and will instead just close everything or the current thing which can cause some weird behavior.
Github Notifications (FHIRcast) (Feb 08 2019 at 16:33):
isaacvetter commented on Issue #69
Makes sense to me, but I'll defer to ya'll's experienced opinion.
@bvdh also made this point during the Jan WGM.
Github Notifications (FHIRcast) (Feb 08 2019 at 20:14):
NiklasSvenzen commented on Issue #69
Yes, I agree. This is true for both close and logout events, where it makes sense to include the context of the closed or logged out item.
Last updated: Apr 12 2022 at 19:14 UTC
