-\subsection{Optimization}
-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
-system-wide one that is reset after am \gls{mTask} finishes. This does require
-separate stacks for each task and therefore increases the system requirements
-of the client software. However, it could be implemented as a compile-time
-option and exchanged during the handshake so that the server knows the
-multithreading capabilities of the client.
-
-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
-the code corresponding to the correct instruction.
-
-\subsection{Resources}
-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.
-
-This 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 preciser 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} can not 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}
-More 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 \gls{TOP}
-paradigm even more and makes programming \glspl{mTask} for
-\gls{TOP}-programmers more seamless. Some of the combinators require previously
-mentioned extension such as the parallel combinator. Others might be achieved
-using simple syntactic transformations.
-
-Currently the \gls{C}-view allows tasks to launch other tasks. 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
-programming and less communication resources. Adding these semantics requires
-modifications to the client software and extensions to the communication
-protocol since relations between tasks also need to be encoded and
-communicated.