ConnectOptions::event_callback mechanism not really ideal

[barafael]

I think the event callback is not optimal for my usecase. I am creating an async_nats::Client, then passing it to a tokio task. This task wants to receive async_nats::Events.
Right now I do this by creating a struct with some state first, then extract an mpsc::Sender from it (it owns the mpsc::Receiver). Then create the client (giving the mpsc::Sender to the ConnectOptions::event_callback). Then, I spawn the future on a tokio task.

Would it be possible to gain access to a watch::Receiver<async_nats::Event> bound to the internal watch channel somehow? It is not possible afaik to use a watch channel in the event_callback because that one requires async move and a watch::Sender is not Clone. To be fair, it is possible to put it in an arc, first...

[Jarema]

I get your point, however I really do not feel ok about exposing internals, as we might want to refactor them at some point in time.

if you prefer watch, first thing I thought about was using an Arc.
We're open for some other ideas or improvements. I just don't have anything in mind that would be a nice improvement without exposing internals.

[Jarema]

@barafael btw if async closures will stabilize this year as it was hinted, we could have a really nice improvement here.