-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}
+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 as a parameter the number of milliseconds to wait
+ in between executions. \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. None of the current client implementations support this.
+ However, registering interrupts on, for example the \gls{Arduino} is
+ very straightforward. 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
+\gls{SDS}. However, the same freedom is not given on the \glspl{SDS} that
+reside on the client. Not all types are suitable to be located on a client.
+Moreover, \glspl{SDS} behave a little different on an \gls{mTask} device
+compared to 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 the update. \glspl{SDS} can update very often and the
+update might not be the final value it will get. This results 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. The existing views can choose to implement it 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}