example(bindings): add async ConfigResolver #4477
Conversation
bindings/rust-examples/client-hello-config-resolution/src/bin/async_load_server.rs
Outdated
Show resolved
Hide resolved
bindings/rust-examples/client-hello-config-resolution/src/bin/async_load_server.rs
Outdated
Show resolved
Hide resolved
…async_load_server.rs Co-authored-by: Sam Clark <3758302+goatgoose@users.noreply.github.com>
- make server config consume self
bindings/rust-examples/client-hello-config-resolution/src/bin/async_load_server.rs
Outdated
Show resolved
Hide resolved
| // If this method took in `&self`, then | ||
| // ``` | ||
| // let config_resolver = ConfigResolver::new(self.server_config(animal)); | ||
| // ``` | ||
| // wouldn't compile because the compiler would complain that `&self` doesn't | ||
| // live long enough. |
There was a problem hiding this comment.
Could you maybe solve this more intuitively by returning a clone of config_resolver instead of consuming a clone of async_resolver_clone? Or does that not work?
There was a problem hiding this comment.
I'm not sure that I'm following (I need to edit that doc comment to refer to the explicit AsyncAnimalConfigResolver, which might have made things more confusing)
server_config(animal) could return a type which directly implements the Future trait, but that would require customers to write all of the actual polling logic for the type, which is very complex and unpleasant.
I originally had this structure as taking in &self but that was also a little tricky, see: #4477 (comment)
I agree that this is a bit unpleasant to deal with, but I think returning a type that directly implemented Future would be even less pleasant
- remove unused struct
- remove unused imports. Need to add this check to CI
Description of changes:
Adds an example showing how to use the async ConfigResolver.
Call-outs:
I haven't decided whether this should be a self contained server, or whether it should just be two separate resolver's that can be used. I think I'm leaning towards the latter.
Testing:
How is this change tested (unit tests, fuzz tests, etc.)? Are there any testing steps to be verified by the reviewer?
Is this a refactor change? If so, how have you proved that the intended behavior hasn't changed?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.