-
Notifications
You must be signed in to change notification settings - Fork 4k
Introduce custom NameResolver.Args #11669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Friendly 1 week ping. This is the domain-specific Key<>-based approach you requested in our last meeting. |
ejona86
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how Extensions was implemented to avoid copying the map on build().
Fully remove Args.Extensions from the public API (@internal) Make TODO non-javadoc google-java-format unused imports
👍 I can't take credit though, just copy pasted from Attributes. LMK if you think one of the other special-purpose containers would be a better fit. |
Update NameResolverTest. Include setAll() coverage
|
Friendly ping :) |
|
Friendly 2 week ping 🙂 |
ejona86
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sending what I have. It is proof at least I looked at this today.
|
Gentle weekly ping |
Call these "custom" args rather than extensions for consistency with CallOptions.
|
NameResolver.Args.Extensions no longer exists. Call these "custom" args to match CallOptions terminology. PTAL |
grpc-binder's upcoming
IntentNameResolverneeds to know the target Android user so it can resolve target URIs in the correct place. Unfortunately, Android's built in intent:// URI scheme has no way to specify a user and in fact theandroid.os.UserHandleobject can't reasonably be encoded as a String at all.We solve this problem by extending
NameResolver.Argsto permit externally defined arguments using the same type-safe and domain-specificKey<T>pattern used byCallOptions,ContextandCreateSubchannelArgs. New "custom" arguments could apply to all NameResolvers of a certain URI scheme, to all NameResolvers producing a particular type ofjava.net.SocketAddress, or even to a specificNameResolversubclass.