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.
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
