+
+The \gls{SDS} functionality in the current system is bare. There is no easy way
+of reusing a \gls{SDS} for another \gls{Task} on the same device or on another
+device. Such functionality can be implemented in a crude way by tying the
+\glspl{SDS} together in the \gls{iTasks} environment. However, this will result
+in a slow updating system. Functionality for reusing shares from a device
+should be added. This requires rethinking the storage because some typedness is
+lost when the \gls{SDS} is stored after compilation. A possibility would be to
+use runtime typing with \CI{Dynamic}s or the encoding technique currently used
+for \CI{BCValue}s. Using \glspl{SDS} for multiple \glspl{Task} within one
+device is solved when the previous point at paragraph~\ref{par:tasklaunch} is
+implemented.
+
+\subsection{Robustness}
+\paragraph{Reconnect with lost devices:}
+The robustness of the system can be greatly improved. Devices that lose
+connection are in the current system not well supported. The device will stop
+functioning and have to be emptied for a reconnect. \Glspl{Task} residing on a
+device that disconnected should be kept on the server to allow a swift
+reconnect and restoration of the \glspl{Task}. This holds the same for the
+client software. The client drops all existing \glspl{Task} on a shutdown
+request. An extra specialization of the shutdown could be added that drops the
+connection but keeps the \glspl{Task} in memory. During the downtime the
+\glspl{Task} can still be executed but publications need to be delayed. If the
+same server connects to the client the delayed publications can be sent
+anyways.
+
+\paragraph{Reverse \gls{Task} sending:}
+Moreover, devices could send their current \glspl{Task} back at the
+server to synchronize it. This allows interchanging servers without
+interrupting the client. Allowing the client to send \glspl{Task} to the server
+is something to handle with care because it can easily cause high bandwidth
+usage.
+
+\section{Conclusion}
+This thesis introduces a novel system for add \gls{IoT} functionality to
+the \gls{TOP} implementation \gls{iTasks}. A new view for the existing
+\gls{mTask}-\gls{EDSL} has been created which compiles the program
+into bytecode that can be interpreted by a client. Clients have
+been written for several microcontrollers and consumer architectures which can
+be connected through various means of communication such as serial port,
+bluetooth, wifi and wired network communication. The bytecode on the devices is
+interpreted using a stack machine and provides the programmer interfaces
+to the peripherals. The semantics of the \glspl{mTask} tries to resemble the
+\gls{iTasks} semantics as close as possible.
+
+The host language has a very efficient compiler and code generator. Therefore,
+compiling \glspl{mTask} is also fast. Compiling \glspl{mTask} is nothing
+more than running some functions native to the host language.
+
+The dynamic nature allows the microcontroller to be programmed once and used
+many times. The program memory of microcontrollers often guarantees around
+$10.000$ write or upload cycles and therefore existing techniques such as
+generating \gls{C} code are not usable for dynamic \gls{Task} environments.
+The dynamic nature also allows the programmer to design fail-over mechanisms.
+When a device is assigned a \gls{Task} but another device suddenly becomes
+unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
+the first device that possibly takes over some of the functionality of the
+broken device without needing to recompile the code.