On Thu, Jan 17, 2013 at 11:50 PM, MinRK <[email protected]> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
