+There are many things to be improved upon in future research. Most likely these
+points will be touched upon in my Master's thesis research.
+\begin{itemize}
+ \item Support task combinators and functions.
+
+ The mTask language already supports the step combinator and it might be
+ fruitful to add for more expressively. Moreover functions would also
+ add a lot. They can be used to share code between tasks to reduce the
+ bytecode size.
+ \item Seamless integration with iTasks.
+
+ At the moment everything works but is hacked together. I would like to
+ extend this with a more robust system that allows adding devices on the
+ fly and adds functionality to monitor the mTask devices.
+ \item Dynamic mTask/SDS allocation.
+
+ Currently all client data for mTask and SDS storage is statically
+ allocated. This means that when only a few tasks are used the memory
+ needed is too high. This can be improved upon by only allocating
+ resources for tasks when they are requested and this would allow the
+ system to run on low memory devices like arduino's.
+ \item Extend on SDSs.
+
+ In the current system the shared data sources used in mTask programs
+ live in a different domain and are synchronized with an iTask
+ counterpart. Programming mTasks could be made more intuitive if you
+ could use standard SDSs from iTasks. Moreover, at the moment only
+ integer and boolean shares are allowed. This really should be extended
+ to at least strings.
+ \item Slicing tasks.
+
+ Every mTask runs in its entirety and to not run into race and
+ scheduling problems loops are not allowed in the mTasks. An improvement
+ to this could be multithreading the tasks by giving them slices of
+ computation and pausing them every slice. In this way loops could be
+ allowed without blocking the entire system. It does require more memory
+ however.
+ \item Run tasks when an interrupt fires.
+
+ Tasks can be scheduled either one-shot or at an interval. It might be
+ useful to tie mTasks to hardware interrupts to increase responsiveness
+ and possibly battery life. These interrupts do not need to be hardware
+ based. A usecase might be to run a task when some other task is
+ yielding a value (see task combinators) or to run a task when a shared
+ data source is received from the server.
+\end{itemize}
+