Re: [Caml-list] Who was working on ocaml bindings for zeromq?

[Goswin von Brederlow <goswin-v-b@web.de>]

On Thu, Jan 16, 2014 at 10:04:04PM +0100, Anders Peter Fugmann wrote:
> Hi,
> 
> At Issuu we are activly maintaing a fork of pdhborges ocaml-zmq
> bindings. We have updated it to support version 3.2 and added new
> features such as socket event listening.
> 
> I do not know how much work it would require to update that to
> version 4.0, but I would expect it to be rather strait forward.
> 
> You can find the github fork here:
> https://github.com/issuu/ocaml-zmq
> 
> Regards
> Anders Fugmann
> 
> 
> 
> On 16/01/14 09:35, Goswin von Brederlow wrote:
> >On Mon, Jan 13, 2014 at 04:58:05PM +0100, Daniel Bünzli wrote:
> >>
> >>
> >>Le lundi, 13 janvier 2014 à 16:48, Goswin von Brederlow a écrit :
> >>
> >>>Hi,
> >>>
> >>>last year someone here was working on bindings for zeromq.
> >>There's at least this:
> >>
> >>>opam list --all | grep zmq | cut -d " " -f 1 | xargs opam info
> >>
> >>              package: ocaml-zmq
> >>              version: 0
> >>           repository: default
> >>         upstream-url: https://github.com/pdhborges/ocaml-zmq/tarball/master
> >>        upstream-kind: http
> >>    upstream-checksum: 8e845370b99630c2a84cf4495480522e
> >>             homepage: https://github.com/pdhborges/ocaml-zmq
> >>              depends: ocamlfind & ounit & uint
> >>    installed-version:
> >>    available-version: 0
> >>          description: OCaml bindings for ZMQ 2.1
> >>
> >>
> >>
> >>Daniel
> >
> >Thanks, those look outdated but good. Combining that with the
> >libsodium bindings David Sheets pointed out and updating to ZMQ 4.0
> >should do the trick.
> >
> >I should start using opam.
> >
> >MfG
> >	Goswin

Does that mean pdhborges is unresponsive to pull requests?

So far I've added support for STREAM sockets to his ocaml-zmq, fixed a
bug in get_byte_socketoption and added a workaround for sending zero
sized strings (stable libzmq gives an EFAULT in zmq_msg_close() with
them). Trivial changes so far. Adding CURVE suport will be a lot more
work. And since I don't need that right now ...


I've been considering interface changes though. Or additions.

1) Track zmq resources with the Gc

Currently you can create a context and sockets and simply forget about
them. The sockets will never be closed and the context never destroyed.
Or you can close/destroy them and still use them.

I would like to add a finalizer to each and a "valid" flag. On
close/destroy the "valid" flag gets set to false. Trying to use them
then would raise an exception. The finalizer would also check the
"valid" flag and if true would print a warning to stderr and close the
socket or destroy the context. This isn't ment as replacement for
manually closing/destroying. Just a safeguard in case you forget.

2) send should have ?no_block and ?more (similar for recv)

I don't like the sndoption variant. Why not simply have 2 optional
bools in send? And lets get rid of the negation too:

val send : ?block:bool -> ?more:bool -> 'a 'a t -> string -> unit

let send ?(block=true) ?(more=false) sock str ) ...

Having them boot also is easier to type. No need to use the module
path.

3) sockets have phantom types, use them

You can't recv from a PUSH socket or send to a SUB socket. The socket
type is already polymorphic with a phantom type. Use that in send/recv
to limit the kinds of sockets that can be used.

4) Polling is ugly

Creating a mask, polling and then figuring out which socket had what
event is complex and every user will have to do that. It would be
better to have another interface with a callback or returning a list
of sockets and events that occured or something.

5) OO interface

I've considered an interface with objects. The usage would then look
something like this:

let ctx = new ZMQ.ctx
let sock = ctx#socket ZMQ.REQ
sock#send "Hello";
Printf.printf "%s\n" sock#recv;
sock#close;
ctx#destroy

Different socket kinds could have different send/recv signatures. For
example ROUTER/DEALER sockets start with routing frames:

val send_msg : ?block:bool -> string list -> string list -> unit

The class would then send the strings with seperaring 0 message and
handle the ZMQ_SNDMORE flag internally.

The OO interface would be simply on top of the existing one. I don't
see why we can't have both.

MfG
	Goswin