-Some functionality of the original \gls{mTask}-\gls{EDSL} will not be used in
-this extension \gls{EDSL}. Conversely, some functionality needed was not
-available in the existing \gls{EDSL}. Due to the nature of class based shallow
-embedding this obstacle is very easy to solve. A type housing the \gls{EDSL}
-does not have to implement all the available classes. Moreover, classes can be
-added at will without interfering with the existing views.
-
-\section{Bytecode compilation}
-The \glspl{mTask} are sent to the device in bytecode and are saved in the
-memory of the device. To compile the \gls{EDSL} code to bytecode, a view is
-added to the \gls{mTask}-system called \CI{ByteCode}. As shown in
-Listing~\ref{lst:bcview}, the \CI{ByteCode} view is a boxed \gls{RWST} that
-writes bytecode instructions (\CI{BC}) while carrying around a \CI{BCState}.
-The state is kept between devices and contains fresh variable names and a
-register of shares used.
+The \glspl{Task} suitable for a client are called \gls{mTask}-\gls{Task} and
+are written in the aforementioned \gls{mTask}-\gls{EDSL}. Some functionality of
+the original \gls{mTask}-\gls{EDSL} will not be used in this system.
+Conversely, some functionality needed was not available in the existing
+\gls{EDSL}. Due to the nature of class based shallow embedding this obstacle is
+easy to solve. A type --- housing the \gls{EDSL} --- does not have to implement
+all the available classes. Moreover, classes can be added at will without
+interfering with the existing views.
+
+\section{\gls{Task} Semantics}
+The current \gls{mTask} engine for devices does not support \glspl{Task} in the
+sense that the \gls{C}-view does. \Glspl{Task} used with the \gls{C}-view are a
+main program that executes code and launches \glspl{Task}. It was also possible
+to just have a main program. The current \gls{mTask}-system only supports main
+programs. Sending a \gls{Task} always goes together with choosing a scheduling
+strategy. This strategy can be one of the following three strategies as
+reflected in the \CI{MTTask} message type.
+
+\begin{itemize}
+ \item\CI{OneShot}
+
+ \CI{OneShot} takes no parameters and means that the \gls{Task} will run
+ once and will then be removed automatically. This type of scheduling
+ could be useful, for example, in retrieving sensor information on
+ request of a user.
+ \item\CI{OnInterval}
+
+ \CI{OnInterval} has the number of milliseconds to wait in between
+ executions as a parameter. \Glspl{Task} running with this scheduling
+ method are executed at predetermined intervals.
+ \item\CI{OnInterrupt}
+
+ The last scheduling method is running \glspl{Task} on a specific
+ interrupt. Unfortunatly, due to time constraints and focus, none of the
+ current client implementations support this. Interrupt scheduling is
+ useful for \glspl{Task} that have to react on a certain type of
+ hardware event such as the press of a button.
+\end{itemize}
+
+\section{\gls{SDS} semantics}
+\Glspl{SDS} on a client are available on the server as well as regular
+\glspl{SDS}. However, the same freedom 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 serializable and representable on clients.
+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.
+
+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}[caption={The \texttt{sdspub} class}]
+class sdspub v where
+ pub :: (v t Upd) -> v t Expr | type t
+\end{lstlisting}
+
+\section{Bytecode compilation view}\label{sec:compiler}
+The \gls{mTask}-\glspl{Task} are sent to the device in bytecode and are saved
+in the memory of the device. To compile the \gls{EDSL} code to bytecode, a view
+is added to the \gls{mTask}-system encapsulated in the type \CI{ByteCode}. As
+shown in Listing~\ref{lst:bcview}, the \CI{ByteCode} view is a boxed \gls{RWST}
+that writes bytecode instructions (\CI{BC}, Subsection~\ref{sec:instruction})
+while carrying around a \CI{BCState}. The state is kept between compilations
+and is unique to a device. The state contains fresh variable names and a
+register of \glspl{SDS} that are used.