Daniel Carbone

For my own product I ended up wrapping the client entirely within my own, with an internal structure that looks a bit like this: ```golang type Client struct { mu...

@kofalt @martin31821: alright, i will have something by Saturday. Looks like its going to rain here all weekend, so perfect timing :)

I have a branch in works: https://github.com/dcarbone/nexus/tree/feature/resilient-client Let me know what you think. One big thing for me is to not block while the client is down, implementors should be...

https://github.com/dcarbone/nexus/blob/feature/resilient-client/client/resilient_client.go contains the code. There are a number of things i would like to clean up and address, namely using determinable errors for `Closed` and `Disconnected` differentiation, and some other...

@martin31821: i retain a separate list of what I've coined "Resilient" procedures and topics. Upon underlying client connection, i call [this](https://github.com/dcarbone/nexus/blob/feature/resilient-client/client/resilient_client.go#L530) method, which will attempt to re-subscribe / re-register as...

@martin31821 at the moment anything done during reconnect is blocked by virtue of the reconnect happening within a `Lock()`, which I could see an argument for modifying. Any actions taken...

@gammazero I disagree. WAMP messages _should_ be ephemeral, and the blocking the entire process without at least providing the implementor some way to cancel the attempt after a period of...

@gammazero I could see that as a course of action, however I think it may be difficult to pass the context all the way down to the socket transmission layer...

These are all excellent points. I agree, lets work on a context-focused model. @gammazero, ideas on where to begin?

What route are you attempting to add?