-
-
Notifications
You must be signed in to change notification settings - Fork 718
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
Incoming support Transport::remote_addr
#713
base: master
Are you sure you want to change the base?
Conversation
I agree, specialization would be the best solution. It might be available in 2034... I'd be fine with exposing the |
If you do not mind break compatibility, I'd like to make a new PR based on your proposation. The reason why I implement this by adding Do you have any roadmap/idea for when we will see the version 0.3 ? |
We could release a v0.3 soon. There's a milestone/tracking issue for breaking changes. I just don't have the time to do them all. |
New PR is comming. Can we merge this into version 0.3 ? Since you don't have time to deal with everything at once, do you mind releasing the preview version first (eg: 0.3-alpha1)? |
merge latest code
update to latest dev code
The current
run_incoming
does not support obtainingremote_addr
dute to impl (PS: always return None).After some investigated, I think the most elegant solution should be to use specialization, so that user can
specialize
his own type override the default impl.Unfortunatly, specialization is not available in stable channel and will not be available in foreseeable future.
So I write a dirty copy-and-paste impl.