simulate properly.
\subsection{Optimization}
+\paragraph{Multitasking on the client:}
True multitasking could be added to the client software. This allows
\gls{mTask}-\glspl{Task} to run truly parallel. All \glspl{mTask} get slices
of execution time and will each have their own interpreter state instead of one
compile-time option and exchanged during the handshake so that the server knows
the multithreading capabilities of the client.
+\paragraph{Optimizing the interpreter:}
Hardly any work has been done in the interpreter. The current interpreter is a
no nonsense stack machine. A lot of improvements can be done in this part. For
example, precomputed \emph{gotos} can improve jumping to the correct part of
this problem.
\subsection{Resources}
+\paragraph{Resource analysis: }
Resource analysis during compilation can be useful to determine if an
\gls{mTask}-\gls{Task} is suitable for a specific device. If the device does
not contain the correct peripherals --- such as an \gls{LCD} --- then the
\gls{mTask}-\gls{Task} should be rejected and feedback to the user must be
given. It might even be possible to do this statically on the type level.
-This idea could be extended to the analysis of stack size and possibly
+\paragraph{Extended resource analysis: }
+The previous idea could be extended to the analysis of stack size and possibly
communication bandwidth. With this functionality ever more reliable fail-over
-systems can be designed. When the system knows precise bounds it can
-allocate more \glspl{Task} on a device whilst staying within safe memory
-bounds. The resource allocation can be done at runtime within the backend
-itself or a general backend can be devices that can calculate the resources
-needed for a given \gls{mTask}. A specific \gls{mTask} cannot have multiple
-views at the same time due to the restrictions of class based shallow
-embedding. It might even be possible to encode the resource allocation in the
-type system itself using forms of dependant types.
+systems can be designed. When the system knows precise bounds it can allocate
+more \glspl{Task} on a device whilst staying within safe memory bounds. The
+resource allocation can be done at runtime within the backend itself or a
+general backend can be devices that can calculate the resources needed for a
+given \gls{mTask}. A specific \gls{mTask} cannot have multiple views at the
+same time due to the restrictions of class based shallow embedding. It might
+even be possible to encode the resource allocation in the type system itself
+using forms of dependant types.
\subsection{Functionality}
+\paragraph{Add more combinators: }
More \gls{Task}-combinators --- already existing in the \gls{iTasks}-system ---
could be added to the \gls{mTask}-system to allow for more fine-grained control
flow between \gls{mTask}-\glspl{Task}. In this way the new system follows the
mentioned extension such as the parallel combinator. Others might be achieved
using simple syntactic transformations.
+\paragraph{Launch \glspl{Task} from a \gls{Task}: }
Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
the current system this type of logic has to take place server side. Adding
this functionality to the bytecode-view allows greater flexibility, easier
protocol since relations between \glspl{Task} also need to be encoded and
communicated.
+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
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
repositories / msc-thesis1617.git / blobdiff