The structure of this thesis is as follows.
Chapter~\ref{chp:introduction} contains the problem statement, motivation,
-related work and the structure of the document.
-Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and
-\gls{iTasks}.
+related work and the structure of the document. Chapter~\ref{chp:top}
+introduces the reader to the basics of \gls{TOP} and \gls{iTasks}.
Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
-methods to create \gls{EDSL}.
-Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is
-extended upon in this dissertation.
-Chapter~\ref{chp:mtaskcont} describes the view and functionality for
-the \gls{mTask}-\gls{EDSL} that were added and used in the system.
-Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that
-are a part of the new \gls{mTask}-system. It covers the client software running
-on the device and the server written in \gls{iTasks}.
-Chapter~\ref{chp:conclusion} concludes by answering the research questions
-and discusses future research.
+methods to create \gls{EDSL}. Chapter~\ref{chp:mtask} shows the existing
+\gls{mTask}-\gls{EDSL} on which is extended upon in this dissertation.
+Chapter~\ref{chp:system} gives an overview of the proposed system.
+Chapter~\ref{chp:mtaskcont} describes the view and functionality for the
+\gls{mTask}-\gls{EDSL} that were added and used in the system.
+Chapter~\ref{chp:arch} shows the implementation and considerations for entire
+system. It covers the client software running on the device and the server
+written in \gls{iTasks}. Chapter~\ref{chp:conclusion} concludes by answering
+the research questions and discusses future research.
Appendix~\ref{app:communication-protocol} shows the concrete protocol used for
communicating between the server and client.
Appendix~\ref{app:device-interface} shows the concrete interface for the
\section{\gls{Task} Semantics}
\input{mtaskext.tasksem}
-\section{\gls{SDS} semantics}
+\section{\gls{SDS} Semantics}
\input{mtaskext.sdssem}
-\section{Bytecode compilation view}\label{sec:compiler}
+\section{Bytecode Compilation View}\label{sec:compiler}
\input{mtaskext.bytecode}
\section{Examples}
--- /dev/null
+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
+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}.
+Some functionality of the \gls{mTask} system is not used.
--- /dev/null
+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.
+
+Chapter~\ref{chp:arch} elaborates on the considerations and implementation of
+the system.
--- /dev/null
+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.
+
+The following terms will be used throughout the following chapters:
+\begin{itemize}
+ \item Device, Client
+
+ These terms denotes the actual device connected to the system. This can
+ be a real device such as a microcontroller but it can also just be a
+ program on the same machine as the server functioning as a client.
+ \item Server, \gls{iTasks}-System
+
+ This is the actual executable serving the \gls{iTasks} application. The
+ system contains \glspl{Task} taking care of the communication with the
+ clients.
+ \item System
+
+ The system describes the complete ecosystem, containing both the server
+ and the clients including the communication between them.
+ \item Engine
+
+ The runtime system of the client is called the engine. This program
+ handles communicating with the server and runs the interpreter for the
+ \glspl{Task} on the client.
+\end{itemize}
+
+\section{EDSL for IoT Tasks}
+\input{system.edsl}
+
+\section{System Overview}
+\input{system.overview}
\chapter[The mTask-EDSL]{The \gls{mTask}-\gls{EDSL}}\label{chp:mtask}
\input{mtask}
+\chapter[mTask system]{\gls{mTask} system}\label{chp:system}
+\input{system}
+
\chapter[Extending the mTask EDSL]{Extending the \gls{mTask} {EDSL}}\label{chp:mtaskcont}
\input{mtaskext}