(This doesn’t affect you if you do not use the newer lower level TCP, TLS, or
IPC APIs for direct communications. That means it doesn’t affect the vast
majority of NNG users.)
I’ve been working on some changes to broaden the reach of NNG and create
general purpose streaming APIs for things like WebSocket, TLS, and TCP. Some
of those have been integrated (although the changes are not in any tagged
release yet).
As I’ve been working through the WebSocket changes, I’ve come to the conclusion
that the attempt to provide a dialer that can be used to dial to different
outbound destinations was a bit of a fool’s errand. In addition, the passing
of an nng_sockaddr is insufficiently descriptive. For example, it does not
convey the PATH component of a URL used with WebSocket at all.
So I’m contemplating two changes:
1. Dialers will have their destination “address” as a single intrinsic
property. This means that we will drop the sockaddr argument from the
xxx_dialer_dial() APIs for low level TCP, IPC, and TLS.
2. I’d like to contemplate changing the allocation functions listeners and
dialers to taking a URL (as a string I think) during allocation. This matches
what we do for the SP protocol stuff (traditional nanomsg). This may allow us
to make use of DNS more easily as well. For example, we could have
“nng_tcp_dialer_alloc(nng_tcp_dialer **, const char *url)” with the URL taking
a form like “tcp://<host>:<port>”. (One side effect of this might be expanded
confusion between the low level API discussed here, and the upper level API
that most people use with nanomsg. I’m not to worried about that.)
These are fairly significant changes, and will involve breaking certain
assumptions that folks using these constructs may have developed. That said, I
don’t think very many folks are using this stuff yet (it’s not in a public
release after all), so hopefully it’s as good a time to update this as any.
If folks have concerns about this, I’d appreciate hearing about it asap.
Garrett
