[nanomsg] Thoughts about nanoconfig
- From: Dirkjan Ochtman <dirkjan@xxxxxxxxxx>
- To: nanomsg <nanomsg@xxxxxxxxxxxxx>
- Date: Thu, 12 Dec 2013 14:34:49 +0100
Hi all,
I've spent this week explaining some of the philosophy behind nanomsg
and building a prototype for a messaging layer. The needs for a
configuration distribution mechanism came up, and yesterday I extended
my prototype with some nanoconfig setup.
I think the nanoconfig philosophy is very solid, but it could be
easier to use in a few ways. Here are some thoughts on making it even
simpler to use.
First, documentation: the current README isn't very easy to read. I
think there should be a few things there on the actual protocol, as I
think that will help users better understand nanoconfig. Secondly,
"nanoconfig://topology1" is used as an example, but that is a pretty
confusing example; it seems to me like the concept of a topology
relates to the actual socket used to connect to the configuration
server, whereas the URL more closely relates to a "role" concept
played by the socket inside the topology. On the other hand, the
example server written in Python seemed very helpful (but I find the
example in YAML pretty unreadable, and the default JSON version isn't
much better).
Second, it seems like the update socket could be specified by the
reply for the initial configuration request, so you don't have to
specify two separate things. Luckily, Paul already has an issue for
that.
Third, it feels to me like the 4th field in a RESOLVE response (the
update key) is kind of useless. Instead, this could be hard-coded to
just use a combination of the URL and the socket type. Are there any
actual other use cases for making this configurable? Seems YAGNI to
me.
Finally, and I guess this is my biggest thing, it seems like it should
be easier to setup. Here's what I envision as my ideal kind of setup:
int db_sock = nc_create_socket("ipc:///tmp/nc.sock", "db-client");
int publisher = nc_create_socket(NULL, "publisher");
In particular, (a) allow the configuration to specify AF and socket
type and (b) make it possible (but optional, in some way!) to specify
nc socket in the code instead of via environment variable. I think the
latter makes it easier to start using nanoconfig in small projects
(i.e. scale down better), where setting up environment variables in a
repeatable fashion is just kind of a pain (no matter how small!).
As for the former, while I recognize that you can obviously not
completely switch out different socket types without changing the
code, I do think that one part of the attraction of nanomsg is how the
socket type is orthogonal to usage API in many ways, and there are
real use cases where being able to switch your sockets from PULL to
SUB without changing the code has meaningful value. Also, using the
socket in ways that are incompatible with its current configuration
seems like it will at least elicit very clear error feedback, so that
any resulting bugs are not so hard to detect. Also, without this it
kind of feels like half of the configuration is in the code while the
other half is out there in the configuration server. It's very
possible there are good technical reasons for this (and if so, they
should be called out in the documentation!), I think complete
configurability makes more sense from an API usage perspective.
So, sorry for the long email, I wanted to write up my thoughts for
others while they were still fresh in my head, and thanks for the cool
software!
Cheers,
Dirkjan
Other related posts:
