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

[Anders Peter Fugmann <anders@fugmann.net>]

Hi Goswin,

Please see my reply below. For completeness your original mail is also 
included in full at the end of the mail.

On 18/01/14 12:33, Goswin von Brederlow wrote:
> Does that mean pdhborges is unresponsive to pull requests?
I guess that he is just busy. He did merge the first set of changes to 
support zmq 3.2, but has yet to merge a set of updates / extenstions to 
the API.

> 1) Track zmq resources with the Gc
Sounds like a nice addition.

> 2) send should have ?no_block and ?more (similar for recv)
We just implemented the exact same interface changes a week ago.

> 3) sockets have phantom types, use them
Agreed.

> 4) Polling is ugly
Indeed this could be made simpler.

> 5) OO interface
I guess OO is a matter of personal taste, but I agree that one does not 
exclude the other.

Pull requests will be most welcome.

Regards
Anders Fugmann


On 18/01/14 12:33, Goswin von Brederlow wrote:
> 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
>>

> 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
>