Closed johns397 closed 5 years ago
Wouter, Yes, but it could be the case that the hub that where the client sends the subscription request has a load balancer and hands off the request to a separate system with a different HubURL. Having the hub report back the HubURL would enable this capability. John
-----Original Message----- From: Wouter Devriendt notifications@github.com To: fhircast/sandbox sandbox@noreply.github.com Cc: johns397 johns397@aim.com; Author author@noreply.github.com Sent: Mon, May 6, 2019 11:23 pm Subject: Re: [fhircast/sandbox] modified: Common/Model/HttpSubscription.cs (#54)
@wdvr commented on this pull request.In Tests/IntegrationTests.cs:> @@ -69,16 +71,33 @@ public class IntegrationTests : IDisposable { return port; }
wouldn't the URL be the load balancer's URL then? I would think this is transparent to the client, the client always talks to the load balancer.
Wouter, I suppose if that's how the load balancer works but there could be other implementations where the subscription receiver delegates the hub responsibility to another system, where that other system wouldn't have the same HubURL. I think being able to return the HubURL gives flexibility for these types of implementations and doesn't seem to be a burden for the hub server to implement in the case where it is the only one. John
-----Original Message----- From: Wouter Devriendt notifications@github.com To: fhircast/sandbox sandbox@noreply.github.com Cc: johns397 johns397@aim.com; Author author@noreply.github.com Sent: Tue, May 7, 2019 1:02 pm Subject: Re: [fhircast/sandbox] modified: Common/Model/HttpSubscription.cs (#54)
wouldn't the URL be the load balancer's URL then? I would think this is transparent to the client, the client always talks to the load balancer.— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
I'll merge this one in. Let's figure out the hubURL parameter as part of https://github.com/fhircast/sandbox/issues/53.