From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 345F17EC6E for ; Sat, 18 Jan 2014 12:33:19 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.15.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArICADtm2lLU4w8OnGdsb2JhbABZg0O2MYVPgQgWDgEBAQEBBg0JCRQogiUBAQEEJwsBRhALGAklDwUoIYgDARgJvXEfhg4TBI4oVweDJIEUBJgghjASjwSBZwEGGQ X-IPAS-Result: ArICADtm2lLU4w8OnGdsb2JhbABZg0O2MYVPgQgWDgEBAQEBBg0JCRQogiUBAQEEJwsBRhALGAklDwUoIYgDARgJvXEfhg4TBI4oVweDJIEUBJgghjASjwSBZwEGGQ X-IronPort-AV: E=Sophos;i="4.95,680,1384297200"; d="scan'208";a="53823486" Received: from mout.web.de ([212.227.15.14]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 18 Jan 2014 12:33:18 +0100 Received: from frosties.localnet ([37.49.32.119]) by smtp.web.de (mrweb004) with ESMTPSA (Nemesis) id 0Ll30X-1VWnUW2tNd-00apiZ for ; Sat, 18 Jan 2014 12:33:17 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.80) (envelope-from ) id 1W4U9M-0003YV-P8; Sat, 18 Jan 2014 12:33:16 +0100 Date: Sat, 18 Jan 2014 12:33:16 +0100 From: Goswin von Brederlow To: Anders Peter Fugmann Cc: caml-list@inria.fr Message-ID: <20140118113316.GA13285@frosties> References: <20140113154808.GA21567@frosties> <20140116083541.GA27229@frosties> <52D84944.8090108@fugmann.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52D84944.8090108@fugmann.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:hIOElFK+uG0xzKthC+86AY5EpfdwINqY+wnWQsHi0sKjBiqqpv1 td0iIvpOGup6etWWQMUAPZQBCTEC+cTLVxzsaCd+hKX7LcYzG3R9jHXIyrowk9QIOThnhvG nsQ0AJSpa1qrOtswNPBQ3kuIEDBdPtj/m9y4AyyELucWrL2QQffFdFmNl03++uYNRC7XY4n 2eY2UI3vV0usAFwvN9qtQ== Subject: Re: [Caml-list] Who was working on ocaml bindings for zeromq? 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