The goal of the system as a whole is to offer a framework of functions with
which an \gls{iTasks}-system can add, change and remove devices at runtime.
Moreover, the \gls{iTasks}-system can send \gls{mTask}-\glspl{Task} ---
compiled at runtime to bytecode by the \gls{mTask}-view --- to the device. The
device runs an interpreter which can execute the \gls{Task}'s bytecode. Device
profiles should be persistent during reboots of the \gls{iTasks}-system. The
methods of interacting with \gls{mTask}-\gls{Task} should be analogous to
interacting with \gls{iTasks}-\glspl{Task}. This means that programmers can
access the \glspl{SDS} made for a device in the same way as regular \glspl{SDS}
and they can execute \gls{mTask}-\glspl{Task} as if they where normal
\gls{iTasks}-\glspl{Task}.

The following terms will be used throughout the following chapter:
\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{Devices}
\input{arch.devices}

\section{iTasks}
\input{arch.itasks}

\section{Communication}
\input{arch.communication}

\section[Lifting mTasks to iTasks-Tasks]%
	{Lifting \gls{mTask}-\glspl{Task} to \gls{iTasks}-\glspl{Task}}
\input{arch.lift}

\section{Example}
\input{arch.example}
