[zeromq-dev] Introducing Caravan: Simple, Faithful ZMQ-Bindings for Objective Caml

[Pedro Borges]

Hi,

I'm the author of ocaml-zmq

On Sun, Apr 3, 2011 at 6:33 PM, Brian Ledger <bpl29 <at> cornell.edu> wrote:

> The exemplifying problem in this domain is how to integrate getsockopt and setsockopt into our interface.  OCaml-ZMQ solves this problem by fragmenting the functions into a set of 21 separately named functions.  Each function has the appropriate argument and result types, so it is impossible for the client to pass data of  the incorrect type to the system.

> Caravan solves this problem more elegantly by using an opaque option type.  The option type abstracts the get and set functions of each option, and each option > is instantiated with the appropriate safety measures for the client.  This keeps intact the original getsockopt and setsockopt functions with their original arguments both ordered and correct.  All that, and the entire mechanism is invisible to the client!

I must say I like your approach very much, however in some cases
having 21 methods allows the user to write the code in a more
declarative fashion  for example "subscribe sock ..." vs "setsockopt
sock subscribe ..." or "has_more sock" vs "getsockopt sock rcvmore".

> No Build Dependencies
> Other than the obvious ZMQ installation, Caravan does not require any additional libraries to run.  This is in contrast to the OCaml-ZMQ project, which uses an unnecessary Uint library to handle unsigned integer options.

Well using Uint keeps the user from passing negative arguments plus
respects the type of the original options so I thought it was
necessary. Why do you think it is unnecessary?


> Error Handling

> The ZMQ guide for writing bindings states "The binding should use [the] standard error mechanism of the language, whether it is error codes, exceptions, etc."  The standard error mechanism in OCaml is the 'try-raise-with' clause.  This obviates the need for zmq_errno, return codes, and cumbersome error frameworks.  However, OCaml-ZMQ is implemented with error codes anyway.

> Caravan maps the POSIX error codes to a series of distinct OCaml exceptions, which are raised in C when an error is detected.  Furthermore, at this granularity, it was possible to specify for each exception it's function-specific message as it was declared in the API.  This means that exceptions are more informative, and can be handled using the natural syntax of OCaml's exception mechanism.

Agreed, revamping exceptions is actually in the roadmap.

Besides the previous diferences there is another one between the two
bindings: ocaml-zmq uses phantom types to prevent the user from
calling subscribe, unsubscribe and create devices with the wrong kind
of socket, while Caravan just allows that to happen. Why am I bringing
up phantom types? Because the phantom types is really the only thing
keeping both both bindings from being merged. If the users feel there
is no real need for the extra type safety, I'll gladly drop the
phantom types, and I'll offer myself to merge the bindings.

Best regards

Pedro Borges