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

[Brian Ledger]

To the ZeroMQ Community,


Caravan represents my interpretation of the Zero-MQ API into Objective
Caml.  It is true that there exists an OCaml-ZMQ binding, but I think that
my implementation will bear comparison.  I will enumerate the features of
Caravan which distinguish it from OCaml-ZMQ.


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


*Type Safety*


The ML family of languages utilize a strictly-typed functional programming
model.  This model makes it possible to detect at compile-time a good number
of programmer errors which otherwise manifest themselves (often
catastrophically) at runtime.


Natively, the OCaml type system is complete, being able to fully determine
and check the types of all functions declared in the language.  However,
integrating foreign function calls introduces a laxity which, if it is not
contained, can conceal programming errors, leading to segmentation faults
and total system failure.


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!



*Faithful API Reproduction*


A barrier to entry for users new to ZMQ is discovering the specific names of
functions and constants relative to the provided API.  This initial cost can
be enough to deter new users from even reaching the desirable point of
evaluation.


The Caravan interface is lexically identical to the published ZeroMQ API in
terms of function names, constants, and order of arguments.  The importance
of this is that new users can directly map the API  into OCaml calls without
the burden of learning each function's special OCaml name.



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


*Small, Simple*


The Caravan library is implemented in six files, including the test and
makefile.  Less code means less opportunity for error.



*Conclusion*


The Caravan binding is not perfect.  Although I have done my best, and to my
knowledge there are no errors, I am sure that there may linger more subtle
errors within my code.  I would like to thank the makers of OCaml-ZMQ for
providing me a valuable reference in this development, for foreign function
interfaces may be difficult to get right, but I am sure that you all have
gone a long way towards hurdling this problem.


Furthermore, the make system in place is minimal, owing to a limited
personal experience with build systems.  I hope that as people test the code
on their own machines, that they contribute their build experiences to the
forks and issues of the Caravan Git.


Ultimately, the question may arise as to which implementation should become
the official ZMQ binding, and I hope that I have made a strong case for
Caravan.  I hope you will all consider my proposal, and I will enjoy the
feedback you create, as this is my first (and hopefully not my last) open
source contribution.  Thank you for your time.


(Caravan is available for download at
https://github.com/bashi-bazouk/Caravan)

-- 
Brian Peter Ledger
Undergraduate of Computer Science
Cornell College of Engineering



*Post Script:*

**

I wrote this letter three days ago, and am hearing now that the 3.0 API is
dropping/dropped.  When this becomes clear enough for me to modify the API
appropriately, I will fork and integrate the new changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110403/e16f93ea/attachment.htm>