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.
+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 sdspub v where
pub :: (v t Upd) -> v t Expr | type t
\end{lstlisting}
+
+Moreover, \glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always anonymous. There
+is no way of labeling it since it is not a real entity, it is just a function.
+When a \gls{SDS} is sent to the device it must be retrievable and identifiable.
+It is not always clear which instantiated \gls{SDS} is which. 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 a \gls{SDS}. The types for this class are as follows:
+
+\begin{lstlisting}[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)) | type, mTaskType, toCode t
+:: Named a b = Named infix 1 a b
+\end{lstlisting}
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.
+strategy. This strategy can be one of the following three strategies:
\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.
+ is useful, for example, in retrieving sensor information on request of
+ the user.
\item\CI{OnInterval}
\CI{OnInterval} has the number of milliseconds to wait in between
Not all \glspl{Task} are suitable to run on an \gls{IoT}-device and therefore
an \gls{EDSL} is used to offer a constrained language to express \glspl{Task}
for the new system in. The \gls{mTask}-\gls{EDSL} shown in
-Chapter~\ref{chp:mtask} provides a language for creating imperative programs
-that are suitable for running on microcontrollers. The \gls{EDSL}'s main view
-is a \gls{C} code generator who's code compiles for \gls{Arduino} compatible
+Chapter~\ref{chp:mtask} provides a language to create imperative programs that
+are suitable to run on microcontrollers. The \gls{EDSL}'s main view is a
+\gls{C} code generator who's code compiles for \gls{Arduino} compatible
microcontrollers. The big downside of this approach is the stiffness of the
system. Once the code has been generated and the microcontroller has been
programmed, nothing can be changed to it anymore. \gls{IoT}-devices often have
a limited amount of write cycles on their program memory available and
therefore it is very expensive to keep recompiling and reprogramming the chips.
To solve this problem, a new view is proposed for the \gls{mTask}-\gls{EDSL}
-which compiles the expressions not to \gls{C}-code but to a bytecode format. To
-achieve this, several classes have been added to the \gls{mTask}-\gls{EDSL}.
+which compiles the expressions not to \gls{C}-code, but to a bytecode format.
+To achieve this, several classes have been added to the \gls{mTask}-\gls{EDSL}.
Some functionality of the \gls{mTask} system is not used.
+
+The added functionality and implementation to the \gls{mTask}-\gls{EDSL} is
+shown in Chapter~\ref{chp:mtaskcont}.
The original \gls{C}-backend for the \gls{mTask}-\gls{EDSL} generated a
self-contained \gls{iTasks} like \gls{TOP} system for a microcontroller. The
proposed backend for the \gls{mTask}-\gls{EDSL} does not result in a
-self-contained system but requires a server to run. The device and the server
-communicate using the Leader/Follower principle\footnote{Also known as
-Master/Slave}. Only the server can initiate a connection with a device and only
-the server can produce and send \glspl{Task} to the device. Concepts such as
-\glspl{SDS} are available on the device and are the main use of communication
-between the client and the server.
+self-contained system but only compiles the expressions to bytecode. The device
+and the server communicate using the Leader/Follower principle\footnote{Also
+known as Master/Slave}. Only the server can initiate a connection with a device
+and only the server can produce and send \glspl{Task} to the device. Concepts
+such as \glspl{SDS} are available on the device and are the main use of
+communication between the client and the server.
Chapter~\ref{chp:arch} elaborates on the considerations and implementation of
the system.
The proposed system provides a bridge between the gap present in the current
-system. It provides a framework of functionality with which an \gls{iTasks}
-server can outsource \glspl{Task} to \gls{IoT}-devices.
+system. It provides a framework to offer functionality for an \gls{iTasks}
+server to outsource \glspl{Task} to \gls{IoT}-devices without needing to
+recompile the code. The \glspl{Task} are compiled to bytecode and interpreted
+on the client.
The following terms will be used throughout the following chapters:
\begin{itemize}
repositories / msc-thesis1617.git / commitdiff