Skip to content
Prev 8729 / 398502 Next

R as a daemon?

Hi Karsten,

(I have been away from e-mail for a week or so and will be back
in the office on Monday 8th. So I'll send this  in the hope that is
useful as the other mail continues on this subject.)


The RSPython interface (http://www.omegahat.org/RSPython) will
probably do what you want quite conveniently. It should be faster than
inter-process communication (since the R interpreter is running within
the python process and sharing the same address space). Also,  it avoids
using strings which are highly server (i.e. R in this case) specific,
lose semantic information and do not allow one to do the things that
we do in the Java, Python, Perl interfaces from R & Splus.

If your architecture does require separate processes for client and
server, CORBA, SOAP or some similar object-oriented remote method
invocation mechanism will probably be mreore robust and useful to you
and others and involve about the same amount of time as implementing
ad-hoc solutions for reading R commands from sockets, etc.  Since R
has a CORBA package and an XML parser, each of these would be
relatively easy to implement for your application .  A CGI script or
whatever would know which "companion object" to send tasks to
and that would handle the persistence of the R process/server.

It might be useful for some of you to know also that I have started
work on an R module for the Apache web server so that R can handle URL
requests directly and generate the contents from a peristent R.  This,
the Perl, Python, Java and CORBA interfaces, the embedded R in
Postgres, etc. are leading towards the need for a threaded version of
R in the longer term. (I would like to know if and how people feel
this would be useful.) And given that framework and possible use , a
security model becomes more necessary and may get implemented. (The
last of these is much further in the future.)  Also, I intend to look
at putting support for SOAP into R and SPlus.

 Hope this helps.
 D.