Hi all, I'm finally getting around to updating pyzmq to use the stable libzmq 3 APIs, since most of the libzmq3 APIs that pyzmq has been using during libzmq3 development are now deprecated.
I have some questions/comments about new APIs: 1. zmq_proxy This is a clone of pyzmq's own MonitoredQueue that does less. MQ does two things that proxy does not: 1. there is a prefix message for messages sent via the side socket, so that receivers can actually tell where they came from 2. MonitoredQueue works with ROUTER:ROUTER configurations, allowing it to act as a multiplexer device. I think zmq_proxy would be a better function if it did one or both of these, but the first would require changing the zmq_proxy API, which is unfortunately set in stone now that there has been a stable release. The inertia involved in a change to zmq_proxy again raises all the same arguments that led to the attempted removal of zmq_device. 2. zmq_ctx_set vs zmq_setctxopt I'm aware that the libzmq API is not internally consistent - these are things we have to deal with. There's a reasonable case to be made that zmq_ctx_set is preferable to zmq_setctxopt on an individual basis, but it's rather annoying when things are not consistent. So in 3.2.2, we have: zmq_ctx_set zmq_msg_set zmq_setsockopt which are equivalent methods for the different zmq objects. It seems to me that it would be preferable to use a consistent pattern, e.g. zmq_FOO_set or zmq_setFOOopt. I'm guessing that the new code suggests that people would prefer zmq_ctx_set zmq_msg_set zmq_sock_set should we add zmq_sock_set/get, so that libzmq is consistent? It's clear that zeromq does not worry about renaming/deprecating functions if devs decide a different name is simply preferable (e.g. zmq_ctx_destroy). In pyzmq, this is reflected by the fact that I think it makes more sense to have `set/get` methods, rather than `Socket.setsockopt` and `Context.set`. I will not allow pyzmq to have an inconsistent API, so I will pick one. If libzmq unifies itself, I will make pyzmq match. If API inertia outweighs consistency in libzmq, then pyzmq will go with generic `get/set` methods, deprecating Socket.setsockopt. 3. zmq_ctx_destroy We now have the unfortunate situation of destroying a context meaning two totally different things. czmq and pyzmq both have a prior notion of destroying a context. This is *distinct* from terminating a context, in that it also closes all of the context's sockets. So now, destroying a context with libzmq and destroying a context with czmq or pyzmq are *totally different*. I propose undoing this change, and renaming zmq_ctx_destroy to zmq_ctx_term, so the name 'destroy' is no longer ambiguous. If someone wants to add true context destruction to libzmq, that would be appropriate, but I don't think it's helpful to re-use a name for a different action. I realize that I missed the window for much of this conversation, because I was writing my thesis while these decisions were made, and libzmq was released, but I would appreciate some input. -MinRK
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
