Page Comparison

...

• A bonus feature would be if they use a shared Synapse cache, it should take less time for the download to occur, but we have to think about the implications of them looking at other datasets already in the cache and bypassing the use agreement logic.
• The crux of the issue is that to use R Studio Server, without major changes, the "RStudio login" has to match up with some UNIX account on the machine one to one, (if five users want to use R Studio Server on the same machine, there needs to be 5 separate UNIX accounts).
• When you use RStudio Server, you can write stuff to your home directory, so its important to clean up afterwards if someone else was going to reuse that same home directory. We can't do a simple round-robin over a fixed set of accounts without cleaning them up between use.
• RStudio Server is written in C++. We don't want to write or support a Synapse C++ client so we should look for solutions that minimize the amount of functionality Synapse-specific we add to RStudio Server as C++ code.
• RStudio Server also uses GWT. Need more detail here, but it may be the case that some of our web functionality could transfer over.
• RStudio Server has no tests. Hundreds of users download the development version on a regular basis and that is how they current test - wait for bug reports from users.
• The RStudio folks have only received one code contribution from an outside developer and they rejected it because the developer did not really understand the inner workings of RStudio Server. The take away is that if we have a contribution that we think should become part of the core project, we should have a design review with them before we code it.

Proposal

Phase 1 Just Get Users Connected to RStudio

Here's an idea for a quick and dirty approach to web-based R for Synapse. If we make the implementation of the auth-plugin for RStudio sound simple and generic enough, perhaps they would be willing to write it for us?

• we have a pool of EC2 hosts running RStudio server behind a load balancer with CNAME rstudio.sagebase.org
  • early on we start out with just a single host, no load balancer, but still use the CNAME
• our services and the custom RStudio auth plugin share a secret key for use in HMAC-SHA1 computation
• if someone on Synapse wants to use RStudio, we redirect them to https://rstudio.sagebase.org:8787/auth-sign-in?securityToken=XXXXXXXX&expires=1317916890&signature=rucSbH0yNEcP9oM2XNlouVI3BH4%3D
  • assumption: not sure whether the securityToken is the Synapse sessionToken or batch API key, either way we may want to re-encrypt it if we are displaying it in clear text in the https url
• this url must be used within 5 minutes to start an RStudio session
• the RStudio auth plugin re-computes the signature on securityToken=XXXXXXXX&expires=1317916890
• if it doesn’t match, the user gets a helpful error message
• if it does match, but the url has expired, the user gets a helpful error message
• if it does match and the url is not expired
  • we use a stable method to compute a unix username from the Synapse securityToken no longer than 32 characters
  • useradd and make the home directory
    • TODO: RStudio Server doesn't run as root so it may contact some daemon running on the box to do the things requiring root privilege
  • put a default .Rprofile in the new home directory to
    1. load and log them into the R Synapse client library(synapseClient); sessionToken(securityToken)
    2. add a package installation directory under the user's home dir if they want to install their own R packages
    3. perhaps configure utilization the shared cache of Synapse data (if we can sort out the data security issues)
• When the users logs out, nuke that unix account and the home directory

Phase 2 Extend RStudio Server to do more stuff

Dave had some more great suggestions such as auto-populating the RStudio edit window with some R client code and incorporating the Synapse Web widget for uploads/downloads. I'll leave it to him to describe those more.