<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 8, 2014 at 2:39 PM, Ciprian Dorin Craciun <span dir="ltr"><<a href="mailto:ciprian.craciun@gmail.com" target="_blank">ciprian.craciun@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">    (Sorry for "reviving" this thread, but only now I've managed to<br>
drain the mail queue.)  :)<br>
<div class=""><br>
<br>
On Fri, Jan 31, 2014 at 9:12 AM, Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br>
</div><div class="">> Why don't we just use gen_tcp and interact with 0MQ peers using the<br>
> wire-line protocol. Erlang is good at getting data in and out of sockets,<br>
> and good at parsing binary packets.<br>
><br>
</div><div class="">> I'm not suggesting implementing all the protocols and transports to start<br>
> with just the REQ - REP protocols of TCP<br>
><br>
</div>> [...]<br>
<br>
<br>
    Implementing a pure Erlang ZeroMQ library that understands only<br>
TCP and some of the basic patterns (such as (X)REQ/REP, PULL/PUSH), as<br>
Joe has suggested, could easily be a weekend project (within some<br>
acceptable performance limits), as the wire protocol is almost<br>
trivial, and the routing logic for the mentioned patterns is simple.<br>
<br>
<br>
    However ZeroMQ offers two orthogonal set of "abstractions":<br>
    * the patterns, which can be natively implemented in Erlang;<br>
    * the transports, some of which can't be implemented in pure<br>
Erlang (e.g. UNIX socket domains);<br>
    * (let alone the other features such as HVM, and the new additions in 4.x);<br>
<br>
    And the true power of ZeroMQ lies in the various ways we can<br>
combine the above features, all interoperable from one language to the<br>
other.  Thus having a myriad of partial implementations would just<br>
break the ecosystem into isolated islands  (like I guess happened with<br>
AMQP).<br>
<br>
<br>
    However...<br>
<div class=""><br>
> ( actually all I want to do is get Erlang talking to Julia - Julia speaks<br>
> 0MQ and I found that I<br>
> couldn't build the Erlang 0MQ bindings with the latest 0MQ - so I'm again<br>
> back to<br>
> "fixing stuff thats broken" in order to do what I want.<br>
<br>
</div>    For such a use-case, and other situations where a full ZeroMQ<br>
library is not needed, one could take the following shortcut:<br>
    * he limits the usage to only (X)REQ/REP or PULL/PUSH, with only<br>
one frame per interaction (plus the "destination" one in case of XREP,<br>
and a "correlation" in case of parallel request / reply sessions);<br>
    * he builds a simple C application which reads / writes on stdin /<br>
stdout messages in the well-supported format <payload-size payload><br>
(maybe one per "destination", "correlation" and "payload") and<br>
translates that to a ZeroMQ `send` / `recv`;<br>
    * he then just uses this executable with `open_port` with `packet`<br>
option;  (which in fact it could be reused in other non-Erlang<br>
environments;)<br>
<br>
    Of course if more about the application is known, one could make<br>
other "simplifications", like use only JSON without embedded newlines,<br>
and transform the protocol into one line per message  (such an<br>
application could be used even from `sh`).  Moreover such an<br>
application could be used at both ends, thus obtaining a poor-man's<br>
messaging solution.  :)<br>
<br>
<br>
    As such I would definitely see the need of both kind of ZeroMQ<br>
interfaces for Erlang (or other languages): a binding based one, and a<br>
"process" based one.<br></blockquote><div><br></div><div>Absolutely - I want to send message to 0MQ the "erlang way"</div><div><br></div><div>To send a message to 0MQ I should say</div><div><br></div>
<div>     Zmq ! IoList</div><div><br></div><div>and *not* call an erlang routine that is the equivalent of some C routine in the ZMQ libraries</div><div><br></div><div>The Erlang Zmq ! Msg should pack data in the appropriate wire-line format and blast it onto the</div>
<div>wire. Incoming messages should be parsed and sent to the appropriate message. </div><div><br></div><div>The trick is to make an interface that makes ZMQ endpoints look and feel like erlang processes.</div><div>We should not "know" that they are ZMQ endpoints. So socket closes should be converted to</div>
<div>exit signals and so on.</div><div><br></div><div>When we talk to Julia we have to perform a load of data conversions - an erlang list is</div><div>[1,2,3] and a julia list is [1 2 3] somebody somewhere must do some conversion. I was thinking that</div>
<div>Erlang could send julia data structures down the wire, and Julia could send Erlang structures</div><div>down the wire since it's far easier to generate Julia in Erlang than parse it, and in Julia it will be</div>
<div>easier to generate Erlang than parse it. JSON would be equally bad for both sides.</div><div> </div><div><br></div><div>/Joe</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
    Ciprian.<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div>