Bug 380567

Summary:	Allow to connect to remote R backends
Product:	[Applications] rkward	Reporter:	Thomas Friedrichsmeier <thomas.friedrichsmeier>
Component:	general	Assignee:	RKWard Team <rkward-devel>
Status:	REPORTED ---
Severity:	wishlist
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	All
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Thomas Friedrichsmeier 2006-12-04 13:42:53 UTC

-- This ticket was imported from http://sourceforge.net/p/rkward/feature-requests/33 on 2017-05-31 14:48:55 +0100 --
I would be nice to be able to connect to an R process running on a different machine. This will require quite a bit of work:

1\) A drop-in replacement for RThread, which sends all data over the network instead
2\) A wrapper for an R process on the other side, which takes this data, and submits it to R just as in REmbedInternal
3\) Configuration options

Comment 1 RKWard Team 2007-02-05 14:49:22 UTC

-- Originally posted by (AT sourceforge.net): nobody --
Logged In: NO 

Why not using RServe for this ?

Comment 2 RKWard Team 2007-02-05 19:44:37 UTC

-- Originally posted by (AT sourceforge.net): nobody --
Logged In: NO 

&gt; Why not using RServe for this ?

Well, while this functionality is in fact fairly similar to RServe, RServe simply does not do everything that is needed. Things that need to be handled include interrupting the current command in R, handling readline\(\) requests, handling other call-backs \(such as invoking the package installation dialog, when require\(\) fails to find the required package\), detecting object changes...

If you'd like to have a look at it: Basically all forms of communication between RThread and REmbedInternal need to be supported \(currently, REmbedInternal is a base class of RThread, but actually, they behave more like two separate modules, and should probably be "divided" in this sense, anyway. Then, perhaps, we can put in a layer between the two \*relatively\* easily.