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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 717257EE99 for ; Sun, 19 Jan 2014 18:16:27 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anders@fugmann.net) identity=pra; client-ip=90.184.182.235; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="anders@fugmann.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of anders@fugmann.net designates 90.184.182.235 as permitted sender) identity=mailfrom; client-ip=90.184.182.235; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="anders@fugmann.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@fw.fugmann.net) identity=helo; client-ip=90.184.182.235; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anders@fugmann.net"; x-sender="postmaster@fw.fugmann.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAGcH3FJauLbr/2dsb2JhbABZg0O8DIEcdIIlAQEBAwEnEUABBQsLGAkWDwkDAgECAUUGDQEHAod5DAnECRMEjigGAQFPB4Q4AQOeaYtRgy47gSwBBgIX X-IPAS-Result: AqEEAGcH3FJauLbr/2dsb2JhbABZg0O8DIEcdIIlAQEBAwEnEUABBQsLGAkWDwkDAgECAUUGDQEHAod5DAnECRMEjigGAQFPB4Q4AQOeaYtRgy47gSwBBgIX X-IronPort-AV: E=Sophos;i="4.95,685,1384297200"; d="scan'208";a="45344151" Received: from 0405ds1-vaer.1.fullrate.dk (HELO fw.fugmann.net) ([90.184.182.235]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 19 Jan 2014 18:16:26 +0100 Received: from [10.0.0.129] (dhcp-129.fugmann.net [10.0.0.129]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fw.fugmann.net (Postfix) with ESMTPSA id 076DA3BEBAC; Sun, 19 Jan 2014 18:16:24 +0100 (CET) Message-ID: <52DC086D.2080508@fugmann.net> Date: Sun, 19 Jan 2014 18:16:29 +0100 From: Anders Peter Fugmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Goswin von Brederlow CC: caml-list@inria.fr References: <20140113154808.GA21567@frosties> <20140116083541.GA27229@frosties> <52D84944.8090108@fugmann.net> <20140118113316.GA13285@frosties> In-Reply-To: <20140118113316.GA13285@frosties> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Validation-by: anders@fugmann.net Subject: Re: [Caml-list] Who was working on ocaml bindings for zeromq? 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 >