% Generated by roxygen2: do not edit by hand
% Please edit documentation in R/messageDS.R
\name{messageDS}
\alias{messageDS}
\title{messageDS}
\usage{
messageDS(message.object.name)
}
\arguments{
\item{message.object.name}{is a character string, containing the name of the list containing the
message. See the header of the client-side function ds.message for more details.}
}
\value{
a list object from each study, containing whatever message has been written by
DataSHIELD into $studysideMessage.
}
\description{
This function allows for error messages arising from the
running of a server-side assign function to be returned to the client-side
}
\details{
Errors arising from aggregate server-side functions can be returned
directly to the client-side. But this is not possible for server-side assign
functions because they are designed specifically to write objects to the
server-side and to return no meaningful information to the client-side.
Otherwise, users may be able to use assign functions to return disclosive
output to the client-side. ds.message calls messageDS which looks
specifically for an object called $serversideMessage in a designated list on
the server-side. Server-side functions from which error messages are to be made
available, are designed to be able to write the designated error message to
the $serversideMessage object into the list that is saved on the server-side
as the primary output of that function. So only valid server-side functions of
DataSHIELD can write a $studysideMessage, and as additional protection against
unexpected ways that someone may try to get round this limitation, a
$studysideMessage is a string that cannot exceed a length of nfilter.string
a default of 80 characters.
}
\author{
Burton PR
}
