\Gls{mTask}-\glspl{SDS} on a client are available on the server as in the form
of regular \gls{iTasks}-\glspl{SDS}. However, the same freedom that an
\gls{SDS} has in the \gls{iTasks}-system is not given for \glspl{SDS} that
reside on the client. Not all types are suitable to be located on a client,
simply because it needs to be representable on clients and serializable for
communication. Moreover, \glspl{SDS} behave a little different in an
\gls{mTask} device compared to in the \gls{iTasks} system. In an \gls{iTasks}
system, when the \gls{SDS} is updated, a broadcast to all watching \glspl{Task}
in the system is made to notify them of the update.  \glspl{SDS} can update
often and the update might not be the final value it will get. Implementing the
same functionality on the \gls{mTask} client would result in a lot of expensive
unneeded bandwidth usage. Therefore a device must publish the \gls{SDS}
explicitly to save bandwidth. Note that this means that the \gls{SDS} value on
the device can be different compared to the value of the same \gls{SDS} on the
server.

To add this functionality, the \CI{sds} class could be extended. However, this
would result in having to update all existing views that use the \CI{sds}
class. Therefore, an extra class is added that contains the extra
functionality. Programmers can choose to implement it for existing views in the
future but are not obliged to. The publication function has the following
signature:
\begin{lstlisting}[language=Clean,caption={The \texttt{sdspub} class}]
class sdspub v where
  pub :: (v t Upd) -> v t Expr | type t
\end{lstlisting}

\glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always attached to a \CI{Main}
component. Thus, they are not usable in the \gls{Task} domain. To solve this,
the \glspl{SDS} found in the \CI{Main} object are instantiated as real
\gls{SDS} in the server. This poses a problem of naming because
\glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always anonymous at runtime. There
is no way of labeling it since it is not a real entity, it is just a function.
When \glspl{SDS} is instantiated and communicated with the device, they must be
retrievable and identifiable. Internally this identification happens through
numeric identifiers, but this is handy for programmers since.
Therefore, an added class named \CI{namedsds} is added that provides the exact
same functionality as the \gls{SDS} class but adds a \CI{String} parameter that
can later be used to identify an \gls{SDS} in the bag of instantiated
\glspl{SDS} that result from compilation. The types for this class are shown in
Listing~\ref{lst:namedsds}. Again, an example is added for illustration.
Retrieving the \gls{SDS} after compilation is shown in
Section~\ref{sec:archexamples}.

\begin{lstlisting}[language=Clean,label={lst:namedsds},%
	caption={The \texttt{namedsds} class}]
class namedsds v where
	namedsds :: ((v t Upd) -> In (Named t String) (Main (v c s))) -> (Main (v c s)) | ...
:: Named a b = Named infix 1 a b

sdsExample :: Main (v Int Stmt)
sdsExample = sds \x.0 Named "xvalue" In
	{main= x =. x +. lit 42 }
\end{lstlisting}
