Open nagisa opened 5 years ago
Indeed! What I imagine this would involve:
zmq_connect
manpage, and construct an Endpoint
enum with a variant for each supported transport.zmq_tcp
), while retaining as much structure as possible.Unknown
variant which simply contains a &str
; I'd rather go without that for now.The resulting enum should then implement Display
for conversion into a string (or buffer), and FromStr
for the opposite direction.
The Endpoint
enum should be unit-tested properly, at least ensuring proper round-tripping from &str
to Endpoint
and back to String
.
This affects the following Socket
methods:
connect
, disconnect
, monitor
and get_last_endpoint
.I have no idea how to incorporate this sensibly without breaking API (without introducing additional methods, which I don't think is worth it), so this would have to go wait for 0.10. If you, @nagisa, or someone else wants to cook up a PR, go for it -- I don't know when I'd come around to giving it a go myself.
While ∅MQ has its own design, it is tailored for C and requires passing in the socket parameters as a string. We could do better! We have
SocketAddr
and all sorts of other cool ways to make the API less stringly.