[zeromq-dev] Initial support for zmq_poll() under Java

Brian Granger ellisonbg at gmail.com
Thu Feb 25 17:25:04 CET 2010


> Are we still aiming for some sort of consistency between the different OO
> scripting language bindings or not? If we are, then we should probably
> coordinate things between Python, Ruby and Java so that they don't diverge
> where practical.

Great question.  As I have developed the new Python bindings I have
thought about this.
Some areas that came up:

* For an OO language, it is awkward to instantiate a Socket by hand
when you have to pass the Context:

s = Socket(ctx, zmq.REP)

A better approach would be to let the context create the Socket:

ctx.create_socket(zmq.REP)

That way, you are sure to get the ctx argument correct.  This is
implemented in the
Python binding.

* It is tempting to make the different socket types subclasses:

SocketBase
RepSocket
ReqSocket
P2PSocket

Rather than using the zmq.REP|REQ... flags.  I did not implement this
as it seemed to
go too afar from the C/C++ bindings.

* I need the ability to bind a Socket to a random port number (0).
Because ZMQ doesn't support
this, I implemented a bind_to_random_port method that tries random
ports in a range until
it finds one and then returns that port number.

http://github.com/ellisonbg/pyzmq/blob/master/zmq/_zmq.pyx#L287

* My interface to poll in modeled on Python's built-in select.poll module:

It has a Poller class which you create and then call register to add
fds/sockets:

p = Poller()
p.register(s1)
p.register(s2)
p.poll(timeout=10)
p.unregister(s1)

* I have added additional methods to the Socket object to serialize
Python objects and send messages in various formats:  send_json,
recv_json (json) and send_pyobj, recv_pyobj (pickle).

Overall, the core API of the Python bindings follows the C/C++ very
closely though.

I am willing to change some of the core API of the Python bindings if
needed but I do think it is important
for each language to create an API that follows the spirit of the language.

Cheers,

Brian


> (Obviously if a language binding does something in a way specific to
> language X then so be it.  But the overall model should be the same
> otherwise they're no longer bindings to the 0MQ API but separate APIs which
> will hurt adoption.)
>
> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com



More information about the zeromq-dev mailing list