[zeromq-dev] new libzmq API

[MinRK]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130117/fad631dd/attachment.htm>