The thing I most dislike about 0MQ is the overly conceptualized socket typing (ZMQ_DEALER etc), and the way the documentation tries to cram all the combinations in to idiomatic 'patterns'.
All I want to be able to express when I send() is:
1. Whether it's a Broadcast, Unicast or Anycast message
2. Whether I'm sending globally, or targeting a
subset of peers (subscribers to some filter).
Forgive me if these mappings are flaky, it's been a while since I used 0MQ.
Target Method ~0MQ socket type
Global broadcast -> ZMQ_PUSH
Global unicast -> ZMQ_PAIR
Global anycast -> ZMQ_DEALER
Subscribers broadcast -> ZMQ_PUB/SUB
Subscribers unicast -> ZMQ_REQ/REP
Subscribers anycast -> ZMQ_ROUTER
When you send() you also need to express how exceptions are handled -- what happens when there are no peers, and what happens when their buffers overflow.
Martin Sustrik did a fine job when he designed those patterns because they are (so far) watertight containers for rather tricky semantics.
Yeah, I'm sure there are loads of technical details... but I can't help feeling there are parallels with the over zealous use of 'patterns' in OOP.
When I started out with 0MQ I felt sucked in to a world of combinatorial explosion where I always have to think about what type of socket is at the other end of of a connect()... it just doesn't feel right to me.
All I want to be able to express when I send() is:
Forgive me if these mappings are flaky, it's been a while since I used 0MQ.