[zeromq-dev] ooc bindings for ØMQ
ph at imatix.com
Thu Jun 17 22:34:53 CEST 2010
On Thu, Jun 17, 2010 at 10:08 PM, gonzalo diethelm <gdiethelm at dcv.cl> wrote:
> In my mind, 0MQ is also a key ingredient in solving another hot topic nowadays: massive parallelism. Good luck training your monkeys to program Scala or F#; I would rather have mine churning out single-threaded, simple modules that communicate among them using 0MQ.
You saw http://www.zeromq.org/blog:multithreading-magic?
> My gut feeling is summarized in this sentence: "if 0MQ didn't exist, it would be necessary to invent it".
Yes, and it's amazing no-one already made it. The best explanation I
can find for that is that the problems 0MQ solves (like where to do
queueing, how to implement patterns, etc.) are really hard to solve
properly and messaging designers invariably seem to need a broker to
focus their thought processes. There have been p2p messaging libraries
before but too complex (e.g. brokerless JMS). And most messaging
products fight to add functionality, no-one ever fought to remove
>> If the data representation layer is to be compatible with this
>> philosophy, it will need to conform to the design, development, and
>> usage patterns that evolve from our experiences with 0MQ.
> Completely agree. The strength in this department lies in having such a light-weight protocol definition that easily bends to become anything one could possibly need.
While this is out of scope for 0MQ core, it makes sense to solve this
problem in such a way that 0MQ users do not have to reinvent the wheel
each time. It's impossible to connect different languages without
some agreed data representation layer and the existing ones all seem
Perhaps time to start looking at what such a data representation layer
should look like. We made some nice ones for AMQP but the challenge
seems to be to avoid representing every possible datatype (at some
point AMQP got multiple ways to represent bits...).
If anyone wants to pull down the AMQP/0.8 spec and look at the data
representation parts, and give an opinion, that might be a place to
start. I'm happy to throw up a straw man RFC if that helps the
> Again, completely agree. I have never understood why it was necessary to invent XML when we have had S-expression for what, half a century now?
S-expression was too simple and would never have spawned an entire
industry of experts :-). Seriously, though, I think XML came from a
more formal document processing environment (SGML) that fit the web
better than S-expression.
> Again, to state it explicitly: thanks to the team for creating 0MQ. It fits perfectly into my infrastructure box.
Thanks to Martin Sustrik for pulling it all together, he is a genius
at Keeping it Simple (and Making it Fast).
More information about the zeromq-dev