+
+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.
+