Implement Channel builder#2675
Conversation
1014b27 to
821aa43
Compare
Make Channel::builder public and update ChannelBuilder::credentials to accept impl IntoDynChannelCredentials instead of Arc<dyn DynChannelCredentials>.
821aa43 to
c0e1055
Compare
…nChannelCredential impl adjustments should handle the type issue when passing DynChannelCredentials internally
| runtime: GrpcRuntime, | ||
| security_opts: SecurityOpts, | ||
| authority: String, | ||
| pub struct MissingOpt; |
There was a problem hiding this comment.
Since users shouldn't need to instantiate this struct, we should add zero-sized private field to prevent this.
pub struct MissingOpt(())| security_opts: SecurityOpts, | ||
| authority: String, | ||
| pub struct MissingOpt; | ||
| pub struct PresentOpt<T>(pub T); |
There was a problem hiding this comment.
Does the inner T need to be pub here? Since the struct is only instantiated by the gRPC crate, I think pub struct PresentOpt<T>(T) should work.
| // TODO(nford): This field is currently unused. When/if it is needed ensure the type is appropriate. | ||
| // - Channels reference SecurityOpts, which hold the value in an Authority object. | ||
| // - All other references currently use "ignored" as the authority. |
There was a problem hiding this comment.
Across languages, there are a few ways to set the channel authority. In order of precedence (highest to lowest), they are:
- User-specified authority in the channel options.
- The authority from the name resolver builder.
- The endpoint from a channel target formatted as
scheme://[authority]/endpoint.
I believe our existing implementation already follows this behavior. I'd suggest we keep the authority handling logic as-is in this PR. Let me know if you have questions about the authority overriding.
|
As discussed offline, I've raised #2694 with only the changes to the trait bounds for the credentials. I'll wait for Doug to review it. |
Introduces a type-builder Channel builder for creating new Channels, using an idiomatic pattern for adding in configuration options.
Motivation
In order to flexibly and ergonomically provide for channel configuration on construction, the type builder is introduced. This allows users to construct channels in a manner similar to:
Solution
The solution uses a 'type builder' so that users can build up their channel configuration over various calls, and the compiler can catch type issues. This also allows us to encapsulate various ergonomics (such as default selection of runtime). This PR implements the critical values at this time and defers additional optional values not being used until a later point. It also leaves work around the internals of the
PersistentChannel/ActiveChannelfor a future PR.Because the public API is being altered, this requires a version bump.