Serverless DataSHIELD Interface (DSI) implementation which purpose is to mimic the behavior of a distant (virtualized or barebone) data repository server (see DSOpal for instance). The datasets that are being analyzed are fully accessible in the local environment. The DataSHIELD configuration (set of allowed aggregation and assignment functions) is discovered at runtime by inspecting the DataSHIELD server-side R packages installed locally. This configuration can also be amended or provided explicitly.
The DSLite “server” (see DSLiteServer) is a R6 class. An instance of this class will host the datasets to be analyzed and the DataSHIELD configuration and will perform the DataSHIELD operations in the context of a session (a contained R environment).
DSLite
can be used to:
The following figure illustrates a setup where a single DSLiteServer holds several data frames and is used by two different DataSHIELD Connection (DSConnection) objects. All these objects live in the same R environment (usually the Global Environment). The “server” is responsible for managing DataSHIELD sessions that are implemented as distinct R environments inside of which R symbols are assigned and R functions are evaluated. Using the R environment paradigm ensures that the different DataSHIELD execution context (client and servers) are contained and exclusive from each other.
The minimum steps to follow for this kind of setup:
DSLiteServer
and provide a named list of these data frames,table
to assign is the name of one the data frames and the url
is the symbol that refers to the DSLiteServer
object,See usage examples.
Article about DataSHIELD: * DataSHIELD: taking the analysis to the data, not the data to the analysis