Hi Corey! Sorry to step into the discussion so late. Have you been looking into nanomsg (http://nanomsg.org/) by Martin Sustrik (the former ZMQ main dev)? He stopped working on ZMQ due to problems arising from the change in their process/licensing by Pieter Hintjens. He wrote some insightful blog posts on 250bpm.org about the choice of C vs. C++ and his preference of statemachines vs. callbacks. He also introduces "scalability protocols" (SP) for general use. Target is the inclusion of SP into the linux kernel for ubiquitous availability. Another plus is that he includes a lot of lessons learned from ZMQ into nanomsg. New things: - It is _pure_ C and not C++. - It has new patterns like survey (collect info from a set of nodes) or bus (a set of nodes are connected like a on a bus). It comes with nanoconf (A dynamic configuration framework to auto discover whole topologies by Paul Colomiets). - Paul also implemented nanocat (commandline interface for nanomsg) - It implements the scalability protocols. - No more "context" needed for socket creation - Thread safe sockets, here we come! (More details http://nanomsg.org/documentation-zeromq.html) Python binding is available https://github.com/tonysimpson/nanomsg-python Current state of nn msg: alpha but useable. Big Plus: it already _has_ pluggable transports (unlike ZMQ) è Maybe you could contribute a RAET transport to nanomsg (C!) (thus reusing the interface and patterns of nanomsg that is even simpler than zmq)? There even is some compile option to make it a drop in replacement for ZMQ (Have not checked recently... but in the transition from ZMQ via X-Roads IO there was)! Right now Martin seems to have a full time occupation somewhere so development of nanomsg is a bit stalled, but there is a community (far from the community around zmq but a community) Maybe SaltStack could step in and drive/fund development a little to push it to stable. IMHO that could be a great benefit for both projects since you do not need to rewrite everything to your own protocol. Just use the scalability of nn_msg to your favor and you don't have to reinvent the wheel. I think @sustrik would like to see a project like SaltStack using nanomsg too (he is the master mind behind the whole thing). Maybe that's a way to help SaltStack (nanomsg is fast and tiny!) and nanomsg at the same time. It might even be feasible to just implement the scalability protocols in python... Johannes Frittum Air Traffic Safety Engineer ATM SysOp AFTN/CIDIN/AMHS-Networkmanager Von: salt-users@xxxxxxxxxxxxxxxx [mailto:salt-users@xxxxxxxxxxxxxxxx] Im Auftrag von Corey Quinn Gesendet: Dienstag, 11. Februar 2014 21:47 An: salt users list Betreff: Re: [salt-users] Salt is dropping 0MQ Just for a bit more clarity, 0MQ support isn't going anywhere. RAET is intended to be added as a secondary option; presuming things go well, it may become the default later in time. Source: I'm the guy in the slide. Regards, Corey Quinn On Feb 11, 2014, at 12:32 PM, Pierre R <p.radermecker@xxxxxxxxx<mailto:p.radermecker@xxxxxxxxx>> wrote: So I am refering to this specific slice. I would be interested in knowing about the 0MQ limitations, dependencies, ... To me 0mq is more a queuing engine than a transport mechanism so I don't really get it. On Tuesday, February 11, 2014 2:31:12 PM UTC+1, Pierre R wrote: Is this mailing list a good place to discuss this topic or is there another place ? Cheers -- You received this message because you are subscribed to the Google Groups "Salt-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@xxxxxxxxxxxxxxxx<mailto:salt-users+unsubscribe@xxxxxxxxxxxxxxxx>. For more options, visit https://groups.google.com/groups/opt_out. <RAET.PNG> -- You received this message because you are subscribed to the Google Groups "Salt-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@xxxxxxxxxxxxxxxx<mailto:salt-users+unsubscribe@xxxxxxxxxxxxxxxx>. For more options, visit https://groups.google.com/groups/opt_out.