Hello, folks--
I am developing a distributed application for which I would like to use ZeroMQ. I've discovered, however, that the zmq egg is unmaintained and very out of date (the egg is compatible with libzmq 2.x, while the current stable version of the C library is 4.05).
The good news is that I was able to bring all the foreign type definitions and API calls up to date, and the code compiles. I don't know yet if its behavior is correct (in fact I know of one thing that is probably incorrect - see below). Anyway, I have several questions related to this.
First of all, shall I take over maintainership of the egg? I'm not really the best person to do this kind of thing - I'm not really a C programmer, and have no real-world experience with ZeroMQ yet. But if there is no better-qualified person available, I'm willing to take on this task. If my plans work out, I expect to be using the egg for several years at least.
Second, the egg documentation mentions that the egg "has some known problems." Can Moritz or someone tell me what those problems are?
Next, there are a couple of details of the code I'm wondering about. One of the significant API changes is in the 'zmq_send' and 'zmq_recv' functions. Both these functions now take a 'len' argument, representing the size of the message buffer. Their signatures are as follows:
int zmq_recv (void *socket, void *buf, size_t len, int flags);
int zmq_send (void *socket, void *buf, size_t len, int flags);
Does a size_t argument require any special handling on the Chicken side? Or can I just treat it as a regular integer?
Another issue with message length is whether there should be a default value. There is a Scheme function that generates a buffer for both sending and receiving functions. Its signature looks like this:
(initialize-message message #!optional data)
The DATA argument is provided when the buffer is used for sending, and not when it is used for receiving. When there is data, the buffer size - and the 'len' argument to 'zmq_send' is derived from the length of the data. The problem arises when receiving a message - when there is no data. For the time being I set the default value to 0 - but that clearly is not going to be a useful value. I suppose the best size for the message buffer would vary greatly according to what type of application you are building, but there has to be some sort of number. Can anyone suggest a reasonable default (the ZeroMQ API doc includes a usage example with a value of 256, but I have no idea how arbitrary that is). Or maybe there just shouldn't be a default, and INITIALIZE-MESSAGE should require a buffer length argument in cases where no data is provided. Any opinions about this?
Finally, if I am going to maintain this egg I would like it to have a test suite. However, I'm somewhat at a loss as to how to test a networking library. Simple unit testing is not going to do much good. Any ideas about how to approach this?
Thanks for any feedback,
Matt Gushee