This forum has been archived. All content is frozen. Please use KDE Discuss instead.

GSoC idea for RKWard: Allow to connect to remote R backend

Tags: None
(comma "," separated)
tfry
Registered Member
Posts
5
Karma
0
RKWard (http://rkward.kde.org) is a GUI and IDE to R (http://www.r-project.org), the popular language for statistical computing. RKWard is not currently ported to KF5, but work on this is expected to start soon.

Current situation: RKWard relies on R to perform statistical computations. For best compatibility and robustness, R is already running in a separate process in this setup. Communication between frontend and backend currently happens using QLocalSocket and (for storable output) HTML files. Communication is already designed to be fully asynchronous. From this it should not be too hard to allow for all communication to be sent over the network, allowing GUI frontend and R backend to run on separate machines. This will come in handy in situations where users need to run R on a server machine, where installation, and remote usage of a frontend like RKWard would not be practical for various reasons.
Further use-cases, that might become enabled as a side-effect, would be the ability to switch between R backends (e.g. different versions of R) at runtime, to re-start a crashed backend, etc.

The task can be divided into a number of fairly independent subtasks. Not all of these would need to be completed at once / in the scope of the GSoC project:
  • Modify the main communication transmitters (RKFrontendTransmitter, RKBackendTransmitter) to optionally support operation over TCP/IP
  • Implement support for connecting to a remote machine, starting the backend process on that, and setting up network channels (e.g. SSH forwarded ports) for communication (currently, starting the backend process is done from RKFrontendTransmitter). At least the client/frontend side of this should work cross-platform, but might rely on helper programs e.g. on putty on Windows.
  • Implement a UI to input the relevant connection parameters, credentials, and provide feedback on failed connection attempts.
  • Modify further communication mechanisms to support operation over TCP/IP:
    • RKGraphicsDevice (also using QLocalSocket, currently)
    • HTML output files, and graphics files created by the backend
    • R package installation/removal (currently runs a separate R process on the command line)
  • Modularize the backend initialization procedure enough to allow starting the frontend without backend, (re-)connecting to an already running backend, switching between different backends at runtime.


Bookmarks



Who is online

Registered users: Bing [Bot], Google [Bot], kesang, Yahoo [Bot]