I think there was some effort from 2.2 to 3.2 to give ZMQ a more similar interface to regular sockets? e.g. Changing the send function to return the number bytes sent on success instead of 0.
So I see zmq_getsockopt/zmq_setsockopt to be mirroring their regular sockets counterpart. On Fri, Jan 18, 2013 at 8:16 AM, MinRK <[email protected]> wrote: > One question about zmq_sock_set. > > There is one major difference about zmq_sock_set from zmq_ctx|msg_set that > I hadn't considered: > > there are non-integer socket options. > > So we have: > > int rc = zmq_ctx_set(ctx, opt, val) > int value = zmq_ctx_get(ctx, opt) > > where the *return* of zmq_ctx_get is the option value. But we can't > really do that with socket options, > since there are a few that aren't ints, and we have > > int rc = zmq_setsockopt(sock, opt, &val, sizeof(val)) > int rc = zmq_getsockopt(sock, opt, &val, &size) > > I don't see any really clean solution. Should we have zmq_sock_set/get, > so the names match, but the signatures don't? > Or do we want zmq_sock_set/get to only work with int socket options and do > something else with the others? > > For instance, what would we do if there ever needs to be a context option > that isn't an int? > > -MinRK > > On Thu, Jan 17, 2013 at 3:32 PM, MinRK <[email protected]> wrote: > >> >> >> On Thu, Jan 17, 2013 at 3:10 PM, Pieter Hintjens <[email protected]> wrote: >> >>> 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 only mean that since there is a stable release with zmq_proxy, >> a change to the API has to have a different name, think about >> deprecation, etc. >> >> >>> >>> 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? >>> >> >> In Python, these are just strings passed to the function as arguments, >> with defaults 'in' and 'out'. >> In libzmq, they could be message or strings, I'm not sure what is best. >> The principal is that if you have a ROUTER-DEALER-SUB proxy, you can tell >> where messages are coming from: >> >> client DEALER connects to ROUTER, sends 'hello' >> ROUTER gets ['IDENTITY', 'hello'] >> DEALER sends ['IDENTITY', 'hello'] >> PUB sends ['in', 'IDENTITY', 'hello'] >> >> service ROUTER at the bottom gets ['IDENTITY2', 'IDENTITY', 'hello'] >> replies with ['IDENTITY2', 'IDENTITY', 'I heard you'] >> DEALER gets ['IDENTITY', 'I heard you'] >> ROUTER sends ['IDENTITY', 'I heard you'] >> PUB sends ['out', 'IDENTITY', 'I heard you'] >> >> client receives ['I heard you'] >> >> using zmq_proxy in its current form, messages in either direction are >> indistinguishable - there's no way to tell if 'I heard you' is a request or >> a reply. >> >> >>> * what precisely do you mean with ROUTER-ROUTER configurations? >>> >> >> a ROUTER-ROUTER device can be used as a multiplexer, >> but you must swap the first two message parts to get the identity routing >> right: >> >> client DEALER (identity CLIENT) >> service ROUTER sets identity 'SERVICE' >> >> device has two ROUTERs - R1, R2, client connects to R1, service to R2. >> >> client sends ['SERVICE', 'request'] >> R1 receives ['CLIENT', 'SERVICE', 'request'] >> device swaps identities >> R2 sends ['SERVICE', 'CLIENT', 'request'] >> service receives ['CLIENT', 'request'] >> >> service sends ['CLIENT', 'reply'] >> R2 receives ['SERVICE', 'CLIENT', 'reply'] >> R1 sends ['CLIENT', 'SERVICE", 'reply'] >> client receives ['SERVICE', 'reply'] >> >> So now you can connect a collection of services to one of these proxies, >> and clients use the proxy as a service multiplexer based on service >> socket identities. >> >> >> >>> >>> > 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? >>> >> >> I'll get started, I just wanted to check in before writing code. >> >> Thanks! >> >> -MinRK >> >> >>> >>> -Pieter >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> >> > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
