-
Notifications
You must be signed in to change notification settings - Fork 55
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
feat(x): make config support PacketListeners and make dependencies explicit and decoupled #304
Conversation
BTW, I believe it's possible to reduce some of the duplication with Generics. I'll explore that in parallel, but I wanted to advance this PR regardless of that. |
BTW, I am not changing the config format yet, but I introduced a The flow is: |
FYI, example QUIC support using this change: #305 |
Changed the code to use Generics and save coding. |
ba74e88
to
866f9c1
Compare
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.
Thanks for the refactoring, it is great!
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.
Another look?
Any thoughts? |
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.
Thanks for the update! Approved with some updates to the doc.
Co-authored-by: J. Yi <93548144+jyyi1@users.noreply.github.com>
Co-authored-by: J. Yi <93548144+jyyi1@users.noreply.github.com>
Properly Support PacketListeners in the Config
As I design the advanced config for Outline, I ran into the issue that we need to support PacketListeners for both the Outline Client and to use QUIC. This PR allows PacketListeners to have a nested config like we have for dialers. I also added support to register types.
Explicit and decouples dependencies
The factory functions used to take as input factory functions for stream and packet dialers, regardless whether they needed them or not. This made dependencies unclear and not enforceable at compile time.
It also doesn't scale well, as more advanced strategies may need dependencies of different types. With the introduction of PacketListeners, I already ran into that issue. However, instead of adding a PacketListener factory to the factory function, I simplified the registration function to only take the context and config. The extra dependencies are passed explicitly then you create the factory function. This ensures compile checks, and allows us to inject any dependency we want, without needing to change the API.
Include Context
I now pass a Context to factory functions. This will allow us to inject deadlines or cancel creation for dialers that take long (e.g. Smart Dialer, Psiphon). It may also allow us to inject a structure for "named dialers" in the future.