[erlang-questions] Erlang deamon question

[Anthony Molinaro]

Hi Nicholas,

I used Paul's instructions here

http://dukesoferl.blogspot.com/2010/01/minor-erlang-interface-tricks.html

along with erlstart

http://code.google.com/p/erlrc/source/browse/trunk/erlstart/

to have a single beam running on a box.  Then if I need to run a remote command
I can run "erlstart-eval '<erlang code>'" to eval some erlang in the running
beam, or "erlstart-remsh" to get a remote shell on the running vm.

I also use erlrc and framewerk to create rpms for all my erlang applications,
which makes deployment of applications and sub-applications easy, at it
usually just involves 'yum install <new version of some erlang application>'
and erlrc does the upgrade via the release_handler.

Anyway, you can use erlstart standalone if you just want an easy remote shell,
shell evaluator, and etop for a locally running beam.

-Anthony

On Tue, Mar 09, 2010 at 02:46:13PM -0500, Nicholas Frechette wrote:
> Hi,
> Supposed I had a single erlang application running as a deamon/service in a
> VM.
> What would be the best way to communicate with it with a command line
> application, keeping in mind I could have any number of them running at the
> same time.
> I am under the impression that I cannot reuse the built in erlang node
> communication protocol (erl -name foobar) and rpc:call mainly because I
> would have to generate random names for my client applications every time it
> is ran, and that could pollute the atom pool of the service. Note also that
> I can trust the clients and am not concerned about security here.
> 
> I presume I am stuck implementing a socket based rpc module? Is there
> something already done for this in erlang? I really would love to just reuse
> erlang terms in my arguments/return values. I am unlikely to have clients in
> other languages but cross language usage could be a plus.
> 
> Thoughts?
> Nicholas

-- 
------------------------------------------------------------------------
Anthony Molinaro                           <anthonym@REDACTED>