[GH-ISSUE #972] trust-dns-resolver compatibility on Fuchsia #580

New issue

Closed

opened 2026-03-15 23:16:14 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 23:16:14 +03:00

Owner

Originally created by @chunyingw on GitHub (Dec 26, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/972

Hey Ben,

I am looking into trust-dns-resolver crate and making tokio crate optional so that Fuchsia does not need to download tokio.

My current approach is to define FuchsiaConnectionProvider which implements the trait ConnectionProvider and FuchsiaConnection type which implements DnsHandle, and I am able to define the type pub struct Resolver { resolver: AsyncResolver<FuchsiaConnection, FuchsiaConnectionProvider>, }
With this approach I am able to run similar test cases such as test_lookup_google (lookup IP address for host) defined in async_resolver.rs successfully as a proof of concept.

The pros is that there is not breaking changes, the cons is I need to duplicate quite a few codes in fuchsia's library such as the definition of enum ConnectionConnect, enum ConnectionBackground etc. which are pretty similar for the ones used for tokio case.

The other approach I may think of is to make types such as TokioConnection, TokioConnectionProvider generic and rename it, so the same definition could be reused. Obviously the cons is there will be breaking changes.

Do you have any opinion on this? Please let me know. Thanks!

Originally created by @chunyingw on GitHub (Dec 26, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/972 Hey Ben, I am looking into `trust-dns-resolver` crate and making tokio crate optional so that Fuchsia does not need to download `tokio`. My current approach is to define `FuchsiaConnectionProvider` which implements the trait `ConnectionProvider` and `FuchsiaConnection` type which implements `DnsHandle`, and I am able to define the type ```pub struct Resolver { resolver: AsyncResolver<FuchsiaConnection, FuchsiaConnectionProvider>, }``` With this approach I am able to run similar test cases such as `test_lookup_google` (lookup IP address for host) defined in async_resolver.rs successfully as a proof of concept. The pros is that there is not breaking changes, the cons is I need to duplicate quite a few codes in fuchsia's library such as the definition of `enum ConnectionConnect`, ` enum ConnectionBackground` etc. which are pretty similar for the ones used for tokio case. The other approach I may think of is to make types such as TokioConnection, TokioConnectionProvider generic and rename it, so the same definition could be reused. Obviously the cons is there will be breaking changes. Do you have any opinion on this? Please let me know. Thanks!

kerem

2026-03-15 23:16:14 +03:00

closed this issue
added the
platform:fuchsia
label

kerem commented

2026-03-15 23:16:30 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 26, 2019):

The other approach I may think of is to make types such as TokioConnection, TokioConnectionProvider generic and rename it, so the same definition could be reused. Obviously the cons is there will be breaking changes.

Could still have default impls of TokioConnectionProvider and TokioConnection that both implement the Generic type you come up with? I agree that we should try to avoid duplication of code. Connection and ConnectionProvider are effectively internal traits, so a breaking change there is fine, IMO, I also don't mind going straight to 0.19 in the name of progress.

@bluejekyll commented on GitHub (Dec 26, 2019): > The other approach I may think of is to make types such as TokioConnection, TokioConnectionProvider generic and rename it, so the same definition could be reused. Obviously the cons is there will be breaking changes. Could still have default impls of TokioConnectionProvider and TokioConnection that both implement the Generic type you come up with? I agree that we should try to avoid duplication of code. Connection and ConnectionProvider are effectively internal traits, so a breaking change there is fine, IMO, I also don't mind going straight to 0.19 in the name of progress.

kerem commented

2026-03-15 23:16:35 +03:00

Author

Owner

@chunyingw commented on GitHub (Dec 26, 2019):

Sure, that makes sense.

On Thu, Dec 26, 2019, 5:15 PM Benjamin Fry notifications@github.com wrote:

The other approach I may think of is to make types such as
TokioConnection, TokioConnectionProvider generic and rename it, so the same
definition could be reused. Obviously the cons is there will be breaking
changes.

Could still have default impls of TokioConnectionProvider and
TokioConnection that both implement the Generic type you come up with? I
agree that we should try to avoid duplication of code. Connection and
ConnectionProvider are effectively internal traits, so a breaking change
there is fine, IMO, I also don't mind going straight to 0.19 in the name of
progress.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/bluejekyll/trust-dns/issues/972?email_source=notifications&email_token=ALDCQHBAKJ4DMLD7765KCLTQ2UUJPA5CNFSM4J7Q5T62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHWGUKQ#issuecomment-569141802,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALDCQHDAG63Q4XO2JGYV3WTQ2UUJPANCNFSM4J7Q5T6Q
.

@chunyingw commented on GitHub (Dec 26, 2019): Sure, that makes sense. On Thu, Dec 26, 2019, 5:15 PM Benjamin Fry <notifications@github.com> wrote: > The other approach I may think of is to make types such as > TokioConnection, TokioConnectionProvider generic and rename it, so the same > definition could be reused. Obviously the cons is there will be breaking > changes. > > Could still have default impls of TokioConnectionProvider and > TokioConnection that both implement the Generic type you come up with? I > agree that we should try to avoid duplication of code. Connection and > ConnectionProvider are effectively internal traits, so a breaking change > there is fine, IMO, I also don't mind going straight to 0.19 in the name of > progress. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/bluejekyll/trust-dns/issues/972?email_source=notifications&email_token=ALDCQHBAKJ4DMLD7765KCLTQ2UUJPA5CNFSM4J7Q5T62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHWGUKQ#issuecomment-569141802>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ALDCQHDAG63Q4XO2JGYV3WTQ2UUJPANCNFSM4J7Q5T6Q> > . >

kerem commented

2026-03-15 23:16:40 +03:00

Author

Owner

@chunyingw commented on GitHub (Jan 8, 2020):

Fixed with https://github.com/bluejekyll/trust-dns/pull/975.

@chunyingw commented on GitHub (Jan 8, 2020): Fixed with https://github.com/bluejekyll/trust-dns/pull/975.

kerem referenced this issue

2026-03-16 02:11:22 +03:00

[PR #580] [MERGED] bump resolver to 0.10.0-alpha.3 and client/server to 0.15.0-alpha.2 #1526