[zeromq-dev] new libzmq API
Pieter Hintjens
ph at imatix.com
Fri Jan 18 00:10:47 CET 2013
On Thu, Jan 17, 2013 at 11:50 PM, MinRK <benjaminrk at gmail.com> wrote:
> 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.
I don't see any inertia. No-one's made a pull request that was refused
or delayed, and since zmq_proxy was new, and I suspect few people use
it, I think extending or changing the API would be uncontroversial.
zmq_proxy was waiting for some suggestions, it's obviously a first
draft.
I'm not familiar with the MQ functionality, perhaps you can explain more:
* is the prefix configurable, and if so, how do you configure it?
* what precisely do you mean with ROUTER-ROUTER configurations?
> 2. zmq_ctx_set vs zmq_setctxopt
You mean zmq_sock_set vs. zmq_setsockopt, right?
> 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).
Yes, I think we've rolled over from the old inconsistent API to a
cleaner one without breaking applications. The deprecated names will
stay there as long as anyone needs them.
I like your suggestion of zmq_sock_set and zmq_sock_get, it makes
great sense. Consistency is worth striving for.
For a start I'd definitely use this syntax in the binding; it's
already the style used in CZMQ (zsocket_set_xxx).
> 3. zmq_ctx_destroy
>...
> 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.
:-) Yes, these are great criticisms that would have been helpful a
while back. Better late than never, and I hope your thesis was a hit.
+1 on renaming zmq_ctx_destroy to _term and deprecating _destroy.
Do you want to make these changes or should someone else?
-Pieter
More information about the zeromq-dev
mailing list