add profile name to TransportChannel

[jaymode]

The NettyTransportChannel has a profile name, which is the name of the profile that the channel belongs to. These profiles allow for binding to multiple addresses and/or ports.

After #10350 there is a new TransportChannel implementation, DirectResponseChannel, used in the netty transport, which does not have the profile information. This implementation should provide a profile name to make it easier to deal with logic based on profiles in the netty transport. The name could be something like __local__.

Adding the getProfileName method to the TransportChannel interface may make sense here as other transport implementations may implement the profile concept and those that don't can just return a default name.

[bleskes]

One more note that whether we use __local__ or something else, we need to make sure we don’t allow people to use that name when configuring profiles in their settings (transport.profiles.*). It also seems we use .client in one place. .local then perhaps?

On 08 Apr 2015, at 14:56, Jay Modi notifications@github.com wrote:

The NettyTransportChannel has a profile name, which is the name of the profile that the channel belongs to. These profiles allow for binding to multiple addresses and/or ports.

After #10350 there is a new TransportChannel implementation, DirectResponseChannel, used in the netty transport, which does not have the profile information. This implementation should provide a profile name to make it easier to deal with logic based on profiles in the netty transport. The name could be something like local.

Adding the getProfileName method to the TransportChannel interface may make sense here as other transport implementations may implement the profile concept and those that don't can just return a default name.

—
Reply to this email directly or view it on GitHub.