Hi
I have a feeling that the name service thing is almost an entire new layer on top of the existing API. The evidence: [good arguments]
I agree - the fact that we can implement it today without touching nanomsgs code is also proof. Name resolution provides a function that maps from endpoint names to bind/connect strings and can be implemented using any of the existing tools, like Zookeeper, a database, redis, DNS or a nanomsg service to that purpose.
Some problems to think about: 1. With big clusters it's not realistic to create a record in name service for each box/application/socket. Thus, the name resolution should be rule-based.
Doesn't that depend on bind vs. connect? I imagine there's always a way to formulate a topology to reduce the number of common names that have to be known. Can you give an example where rules are absolutely needed?
2. If so, who evaluates the rule? Does name service do that? Or does in only return the rule and socket is responsible for evaluating it itself?
What does the rule depend on? What information is needed for evaluating it?
I don't follow that last point. Should name resolution really solve that problem? Or should it just solve the problem of turning NAME into a string like "tcp://127.0.0.1:1234"? I would be in favour of the latter.4. Name service response consists of full a list of nanomsg addresses to bind/connect to: bind: "tcp://127.0.0.1:1234" connect: "ipc:///var/run/topology.sock" connect: "tcp://192.168.0.1:2345"Right. Also, socket options could be provided by the name service (priorities, or whatever).
kaspar
