On Oct 24, 2012, at 4:35 PM, Richard D. Morey wrote: > On 24/10/12 10:07 PM, Simon Urbanek wrote: >> On Oct 24, 2012, at 3:47 PM, Richard D. Morey wrote: >> >>> I'd be fine with the poor man's solution (maybe with tempfile()?) if I can >>> get access to the local file via javascript. But I don't think I can, due >>> to the security limitations of the browser. I may have to rethink this >>> significantly. >>> >> That should be no problem, you can have another R instance serving the >> monitoring page (or you can use Rserve's HTTP server and have just one >> instance with arbitrarily many connections as needed). > > OK, I'm looking at Rserve. I get the impression that one needs to start a > separate server, so it would be difficult to make this transparent to a user > who installs my package and just wants to do an analysis with a GUI. It also > appears that there is a separate binary install, at least on Windows, which > would mean anyone using my package would need to install and run something > separate. Is that accurate? >
Not quite - it is all in the Rserve package, many years ago we used to supply Rserve.exe just because it did not require installation of any packages, but we don't do that anymore. Typically Java GUIs use Rserve to run R - it's trivial to start it (e.g., there is the StartRserve.java example) so your GUI can start it and shut it down. I don't know how you are driving your GUI so this may or may not be a good way - on unix you get the benefit of parallel HTTP server, that's really all I was pointing out. BTW: if you are talking web-GUI then Rserve is great for that because the GUI consist simply of R scripts (see FastRWeb) - but I mat be thinking bigger than what you have in mind. The point is that you need a separate monitoring process or threads. That process can be R, Rserve or any thing else. Cheers, Simon ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
