∅MQD is a D library that wraps the low-level C API of the ∅MQ messaging framework.  It is a rather thin wrapper that maps closely to the C API, while making it safer, easier and more pleasant to use.  The API is designed to feel familiar to existing ∅MQ users, yet natural to D users.

For more information, check out the following links.

  GitHub/README:  https://github.com/kyllingstad/zmqd
  API docs:       http://kyllingstad.github.io/zmqd
  DUB package:    http://code.dlang.org/packages/zmqd

A while ago, I posted an RFC about this on the digitalmars.D forum.  I've since incorporated some of the suggestions I got and made a few additions, and I now deem the library ready for release.  It hasn't seen a lot of serious field testing yet, though, so there are surely a few bugs lurking in there.  Therefore, I am calling this the first beta release, and encourage you to report any issues you encounter here:

  https://github.com/kyllingstad/zmqd/issues

On Fri, 24 Jan 2014 17:45:44 +0000, Lars T. Kyllingstad wrote:

> ∅MQD is a D library that wraps the low-level C API of the ∅MQ messaging framework.  It is a rather thin wrapper that maps closely to the C API, while making it safer, easier and more pleasant to use.  The API is designed to feel familiar to existing ∅MQ users, yet natural to D users.
> 
> For more information, check out the following links.
> 
>    GitHub/README:  https://github.com/kyllingstad/zmqd API docs:
>    http://kyllingstad.github.io/zmqd DUB package:
>    http://code.dlang.org/packages/zmqd
> 
> A while ago, I posted an RFC about this on the digitalmars.D forum. I've since incorporated some of the suggestions I got and made a few additions, and I now deem the library ready for release.  It hasn't seen a lot of serious field testing yet, though, so there are surely a few bugs lurking in there. Therefore, I am calling this the first beta release, and encourage you to report any issues you encounter here:
> 
>    https://github.com/kyllingstad/zmqd/issues

Nicely done.  It looks like you haven't wrapped the poll functionality at all, something that I use in most of my 0MQ programs.

On Friday, 24 January 2014 at 18:59:54 UTC, Justin Whear wrote:
> Nicely done.  It looks like you haven't wrapped the poll functionality at
> all, something that I use in most of my 0MQ programs.

Thanks!  I'm glad that you mention zmq_poll(); I've been wondering how to deal with that.  It's slightly more low-level than the other functions, since it also deals with standard OS file descriptors, and I'd rather not expose OS-level stuff in ∅MQD more than strictly necessary.  Do you ever use that functionality, or do you just poll ∅MQ sockets?

Lars

On Fri, 24 Jan 2014 19:11:56 +0000, Lars T. Kyllingstad wrote:

> On Friday, 24 January 2014 at 18:59:54 UTC, Justin Whear wrote:
>> Nicely done.  It looks like you haven't wrapped the poll functionality at all, something that I use in most of my 0MQ programs.
> 
> Thanks!  I'm glad that you mention zmq_poll(); I've been wondering how to deal with that.  It's slightly more low-level than the other functions, since it also deals with standard OS file descriptors, and I'd rather not expose OS-level stuff in ∅MQD more than strictly necessary.  Do you ever use that functionality, or do you just poll ∅MQ sockets?
> 
> Lars

I think I've mixed a file descriptor in with sockets once, but not in current production code.  A quick thought: you might template the poll wrapper so that the user could pass a mix of Socket and int (or whatever the proper name is for the file descriptor type per OS).  Inside, you set the appropriate property on each zmq_pollitem_t structure based on the argument type.

Now that I think of it, you also need to find a scheme for indicating which events you want to listen for.  Which means either a simple pairing type (socket, event mask) or a getopt-style interface.

On Friday, 24 January 2014 at 19:20:26 UTC, Justin Whear wrote:
> Now that I think of it, you also need to find a scheme for indicating
> which events you want to listen for.  Which means either a simple pairing
> type (socket, event mask) or a getopt-style interface.

I have suggested a few possible poll APIs here:

    https://github.com/kyllingstad/zmqd/issues/3

Comments are very welcome.