Stream: fhircast-github
Topic: docs / Issue #33 why must a subscriber have a publically ...
Github Notifications (FHIRcast) (May 17 2018 at 23:01):
isaacvetter opened Issue #33
During the HL7 working group meeting in May in Köln, there was strong feedback from @bvhd and @joshmandel a subscriber ought not to be required to host an accessible url. WebSub requires that the subscriber host an accessible url which receives notifications.
This requirement can dictate a subscriber's use of a client/server architecture. Alternatives could include using a long-running server/client communication method such as HTTP Long-Polling/Comet, HTML Server Sent Events (SSE) or websockets, thereby allowing the subscriber to not host a url accessible to the Hub.
The downside to these approaches is that the use of proxies (proxy or reverse proxy servers, firewalls, load-balancing routers and so on) between the browser and the Hub which are often designed for short-lived HTTP requests and multiple network hops increase the expense of keeping sockets.
Generally, long-polling is the most primitive and expensive method. Server-Sent Events are uni-directional (server->client) and further, are not supported by IE 10 or 11. Websockets is the server <->client contender.
Is the use of websockets viable? Hosting FHIRcast applications within the same network as the Hub would help address common problems experienced due to proxies. What about a hub or client hosted within a multi-application/user app server, such as Citrix? -- a common deployment method for fat clients in healthcare.
Github Notifications (FHIRcast) (May 18 2018 at 12:58):
jeremysrichardson commented on Issue #33
Now we're getting somewhere.
As a physician, I would like to have a local application, behind a firewall, share patient context with an application on the internet because (See all reasons for FHIRCast)
Github Notifications (FHIRcast) (May 18 2018 at 13:06):
jeremysrichardson commented on Issue #33
@NiklasSvenzen at Sectra was using SignalR (https://github.com/aspnet/SignalR)
We use SignalR in some of our products at MModal.The advantage we found is that the library is easy to implement in web clients and .Net apps.
I'm pretty sure we would have no problem contributing code if we wanted to go this direction and might be able to help setup a reference implementation.
I could see this approach being useful for server and client based hubs -- a client based hub would allow you to avoid having a server, which I found super useful in early CCOW development many years ago.
Github Notifications (FHIRcast) (May 18 2018 at 13:12):
jeremysrichardson {} a comment on Issue #33
@NiklasSvenzen at Sectra was using SignalR (https://github.com/aspnet/SignalR)
We use SignalR in some of our products at MModal.The advantage we found is that the library is easy to implement in web clients and .Net apps.
I'm pretty sure we would have no problem contributing code if we wanted to go this direction and -might be able to- will commit to help setup a reference implementation.
I could see this approach being useful for server and client based hubs -- a client based hub would allow you to avoid having a server, which I found super useful in early CCOW development many years ago.
Github Notifications (FHIRcast) (May 18 2018 at 13:13):
jeremysrichardson {} a comment on Issue #33
@NiklasSvenzen at Sectra was using SignalR (https://github.com/aspnet/SignalR)
We use SignalR in some of our products at MModal.The advantage we found is that the library is easy to implement in web clients and .Net apps.
I'm pretty sure we would have no problem contributing code if we wanted to go this direction and will commit to help setup a reference implementation.
I could see this approach being useful for server and client based hubs -- a client based hub would allow you to avoid having a server, which I found super useful in early CCOW development many years ago.
Github Notifications (FHIRcast) (May 18 2018 at 13:13):
jeremysrichardson {} a comment on Issue #33
@NiklasSvenzen at Sectra was using SignalR (https://github.com/aspnet/SignalR)
We use SignalR in some of our products at MModal.The advantage we found is that the library is easy to implement in web clients and .Net apps.
We would contribute code if we wanted to go this direction and will commit to help setup a reference implementation.
I could see this approach being useful for server and client based hubs -- a client based hub would allow you to avoid having a server, which I found super useful in early CCOW development many years ago.
Github Notifications (FHIRcast) (May 24 2018 at 20:13):
isaacvetter commented on Issue #33
Hey @jeremysrichardson !
If you're able and interested, code contributions definitely accepted for the sandbox, we've even got a few open issues following the connectathon last week.
SignalR is great, in large part because it handles the selection of the actual over the wire transport protocol. SignalR actually supports 3-4 different communication mechanisms and degrades gracefully through them. My take is that for bidirectional communication, websockets is the clear winner.
I'd suggest that a reason SignalR does this is because of the lack of support across clients and environments for websockets.
In your products that use SignalR, how often do they fall back to long-polling? Do you own the client and the server? Are both the client and the server within the intranet?
Isaac
Last updated: Apr 12 2022 at 19:14 UTC
