-
Notifications
You must be signed in to change notification settings - Fork 165
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
Expose internal command mpsc::channel
in public API
#1266
Comments
Hey! Thank you for your proposal and suggestion! I understand that use case and having a nice way to use sink would be good, however I do not like exposing As usual I'm against any unnecessary layers of indirection, in this case, I would prefer having one. |
That's understandable, so how about the In fact, it could be a |
Proposed change
I'd like to expose
nats.rs/async-nats/src/client.rs
Line 69 in ec6331c
Sink<async_nats::Command>
in some way (or even just a plain channel) - see use case belowThis could look like
or simply
This would require making
async_nats::Command
publicThis would be an advanced functionality and I'm happy to e.g. guard this by an opt-in feature flag if there are concerns around that
The sender -> sink mapping itself is facilitated by https://docs.rs/tokio-util/latest/tokio_util/sync/struct.PollSender.html#impl-Sink%3CT%3E-for-PollSender%3CT%3E
Use case
I'm using NATS as a byte stream transport and to facilitate that I'd like to implement a
Sink
pairing a client and a subject. Unfortunately, plainpublish
and related functionality does not provide enough data to be able to do that correctly.Contribution
yes, will do so in a few hours
The text was updated successfully, but these errors were encountered: