-sense that the \gls{C}-view it does. \glspl{Task} in the new system are are
-\CI{Main} objects with a program inside. A \gls{Task} runs periodically, on
-interrupt or one-shot.
-\todo{elaborate}
-
-\subsection{\glspl{SDS}}
-\glspl{SDS} behave a little bit differently on an \gls{mTask} device than in
-the \gls{iTasks} system. In an \gls{iTasks} system, when the \gls{SDS} is
-updated, a broadcast to everyone in the system watching is made to notify them
-of an update. \glspl{SDS} on the device can update very often and the update
-might not be the final value it will get. Therefore a device must publish the
-\gls{SDS} explicitly to save bandwidth. This means that an extra function is
-added to the \CI{sds} class that adds the \CI{pub} function.
-\todo{elaborate}
-
-\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.
+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.