On 09/05/16 17:58, Justin Ross wrote:
Hi, Jakub. Here's my proposal (two versions).## Version 1 - Dispatch defines "applications" as policy domains - Dispatch uses one of the following, in descending priority, to identify the app: - open.properties["application-id"] (real property name to be determined later) - open.hostname ("virtual host") - TCP connection level host (the "physical" or network host) - APIs and tools should offer ways to control the application ID and hence override the policy domain that is used ## Version 2 - Dispatch defines "vhosts" as policy domains - Dispatch uses one of the following, in descending priority, to identify the app: - open.hostname ("virtual host") - TCP connection level host (network host) - The policy domain in use can only be determined by virtual host or network host I favor version 1, on the idea that dispatch policy domains should have a more flexible scope.
I favour version 2, I think. I don't think the application should be responsible for identifying the policy domain that applies to it. Using virtual hosts is a well known approach. I could also envisage that a listener config could define the policy to apply (or the default policy).
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
