<div dir="ltr"><div>Hi David,<br><br>sounds a bit like you want to treat your C node as a resource, and that's a perfect match for a gen_server.<br><br>I would simply hide all interaction with the C node *inside* the gen_server. Your send/receive to the C node could therefore be handled completely inside a gen_server call. You would still have the top level function get_version(), but that would only do the gen_server:call, and the handle_call then does the send to the C node and waits for the answer with a receive.<br>
<br></div><div>Hoe that makes sense,<br></div>Robby<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 January 2014 09:17, David Welton <span dir="ltr"><<a href="mailto:davidnwelton@gmail.com" target="_blank">davidnwelton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am working with a system that looks like this:<br>
<br>
C node <=======> Erlang <========> Java Node<br>
<br>
And we're looking at good ways to integrate everything.<br>
<br>
For instance, we want the Java node to be able to do a simple query<br>
that ends up getting some data from the C node, say, the version it's<br>
running or something like that.<br>
<br>
Since the Java code needs to be simple, we want to do the equivalent<br>
of rpc:call(hw_server, get_version, []) and wait for the answer. It<br>
shouldn't take long, and timeouts or whatever can be handled by Java<br>
in that case.<br>
<br>
However, to interact with the C node, the gen_server that manages it<br>
would want to do something like:<br>
<br>
{any, 'c@node'} ! get_version<br>
<br>
And then get the answer via handle_info.<br>
<br>
But if we're going to transform what is essentiall a 'call' -<br>
hw_server:get_version() - into a cast/response, somewhere there's got<br>
to be a receive.  For instance:<br>
<br>
get_version() -><br>
   Ref = make_ref(),<br>
   gen_server:cast(hw_server, {get_version, Ref}),<br>
   receive<br>
      {Ref, version, Version} -><br>
          Version<br>
    end<br>
<br>
This feels like I've left OTP behind though.<br>
<br>
We could put the receive in the handle_cast for the gen_server, but<br>
then that's going to block the whole thing on one call, which strikes<br>
me as a bad idea, although I guess it could also be used to protect<br>
the C node if it were unable to process more than one thing at once.<br>
<br>
Another approach would be to further work with our Java guy to have<br>
him send and receive the messages, but we were kind of hoping to hide<br>
some of the complexity from that part of the system.<br>
<br>
Thank you,<br>
<span class="HOEnZb"><font color="#888888">--<br>
David N. Welton<br>
<br>
<a href="http://www.welton.it/davidw/" target="_blank">http://www.welton.it/davidw/</a><br>
<br>
<a href="http://www.dedasys.com/" target="_blank">http://www.dedasys.com/</a><br>
_______________________________________________<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>
</font></span></blockquote></div><br></div>