You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a new DataSHIELD R session on the R server side, it should be possible to specify which flavor of R server setup is to be used at login time.
For instance for a given DS node, there could be R servers with different R versions and/or different R/DataSHIELD packages installed (in different versions) and/or different DataSHIELD configurations (different options, different R/DataSHIELD packages visibility). All these settings make a "profile" which can be uniquely identified by a name.
Permissions may apply on these profiles, so that not all profiles can be used by the requesting user (middleware responsibility)
The profile name may be different from one node to another (additional parameter to login data frame)
When not specified a default profile name is applied ("default")
The implementation must be backward compatible, i.e. if the "profile" feature is not implemented by the DS middleware (Opal/Armadillo/DSLite) instance, the R session will still be created (with a warning).
The profile names can be listed
The DS config, the installed packages and the R version are listed by profile
The implementation of the profiles will affect the login and administration/monitoring API, not the analysis one (assignments and aggregations apply to the created R server sessions).
The text was updated successfully, but these errors were encountered:
When creating a new DataSHIELD R session on the R server side, it should be possible to specify which flavor of R server setup is to be used at login time.
For instance for a given DS node, there could be R servers with different R versions and/or different R/DataSHIELD packages installed (in different versions) and/or different DataSHIELD configurations (different options, different R/DataSHIELD packages visibility). All these settings make a "profile" which can be uniquely identified by a name.
The implementation of the profiles will affect the login and administration/monitoring API, not the analysis one (assignments and aggregations apply to the created R server sessions).
The text was updated successfully, but these errors were encountered: