\section{Finale}
Traditionally, the \gls{IOT} has been programmed using layered, or tiered, architectures.
Every layer has its own software and hardware characteristics, resulting in semantic friction.
+It is hard to orchestrate the smooth cooperation of the individual components, especially during maintenance of the entire \gls{IOT} application.
\Gls{TOP} is a declarative programming paradigm designed to describe multi-tiered interactive systems from a single source.
+Such a tierless system prevents the orchestration problems of the tiered approach.
However, it is not straightforward to run \gls{TOP} systems on resource-constrained devices such as edge devices.
+The type system of the host language checks the \gls{ITASK} and \gls{MTASK} components as well as their interaction.
The \gls{MTASK} system bridges this gap by providing a \gls{TOP} programming language for edge devices.
It is a full-fledged \gls{TOP} language hosted in a tiny \gls{FP} language.
Manual interleaving of imperative code can be automated to certain extents.
Solutions often require an \gls{RTOS}, have a high memory requirement, do not support local variables, no thread-safe shared memory, no composition or no events as described in \cref{tbl:multithreadingcompare}.
This table extends a comparison table with various solutions to multitasking to \gls{MTASK} in the relevant categories.
-%\todo[inline]{Uitleg over de talen geven}
\begin{table}
\begin{threeparttable}
FlowTask & 2011 & \CIRCLE{} & \CIRCLE{} & \Circle{} & \Circle{} & \Circle{} & \Circle{}\\
Ocram & 2013 & \CIRCLE{} & \CIRCLE{} & \Circle{} & \CIRCLE{} & \Circle{} & \Circle{}\\
C\'eu & 2013 & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{}\\
- \gls{MTASK} & 2022 & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \LEFTcircle{}\tnote{1} & \LEFTcircle{}\tnote{2}\\
+ \gls{MTASK} & 2022 & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{}\tnote{1} & \CIRCLE{}\tnote{2}\\
\bottomrule
\end{tabular}
\endgroup
\subsection{Security}
The \gls{IOT} has reached the news concerningly many times regarding the lack of security \citep{alhirabi_security_2021}.
The fact that the devices are embedded in the fabric, are hard to reach and thus to update, and can only run limited cryptographic algorithms due to their constrained resources makes security difficult.
-The security of \gls{MTASK} and the used protocols are deliberately overlooked at the moment
+The security of \gls{MTASK} and the used protocols are deliberately overlooked at the moment.
The \gls{MTASK} language and \gls{RTS} are modular.
For example, the communication channels are communication method agnostic and operate through a simple duplex channel interface.
It should therefore be fairly easy to apply standard security measures to them by replacing communication methods and applying off-the-shelve authentication and encryption to the protocol.
These blocks are marked as such, because in the case of a reset of the system, the work must be done again.
Examples of such blocks are \gls{I2C} transmissions or calculations that rely on recent sensor data.
In \gls{MTASK}, all work expressed by tasks is already split up in atomic pieces of work, i.e.\ the work is a side effect of rewriting.
-Furthermore, creating checkpoints should be fairly straightforward as \gls{MTASK} tasks do not rely on any global state---all information required to execute a task is stored in the task tree.
+Furthermore, creating checkpoints is fairly straightforward as \gls{MTASK} tasks do not rely on any global state---all information required to execute a task is stored in the task tree.
It is interesting to see what \gls{TOP} abstraction are useful for intermittent computing and what solutions are required to make this work.
Mesh networks allow for communication not only to and fro the device and server but also between devices.
For example, it is possible to run tasks or share data with \glspl{SDS} on different machines.
It is interesting to investigate how this networking technique can be utilised in \gls{MTASK}.
-Finally, \glspl{FPGA} have been becoming cheaper and faster recently, allowing for purely functional code to be translated to \glspl{FPGA} code efficiently \citep{baaij_digital_2015}.
+\Glspl{FPGA} have been becoming cheaper and faster recently, allowing for purely functional code to be translated to \glspl{FPGA} code efficiently \citep{baaij_digital_2015}.
It would be interesting to see how and whether (parts of) \gls{TOP} programs or the functionality of the \gls{MTASK} \gls{OS} could be translated to \gls{FPGA} specifications.
\subsection{Formal semantics}
Furthermore, it is unclear whether all derived combinators from \gls{ITASK} can be expressed in terms of \gls{MTASK} combinators.
\Citet{van_der_aalst_workflow_2003} defines a benchmark set of workflow patterns.
It is interesting to see which patterns can be implemented with \gls{MTASK}, and what additional combinators are needed.
-Moreover, editors are a crucial part of \gls{TOP}.
+
+Editors are a crucial part of \gls{TOP}.
In \gls{MTASK}, sensors can be seen as read-only shared editors that are updated by the system.
It is interesting to investigate how actual interactive editors would fit in \gls{MTASK}.
For example, many smartwatches contain touch sensitive screens that could be used to interact with the user in this way.
\subsection{Using mTask in practise}
Funded by the Radboud-Glasgow Collaboration Fund, collaborative work was executed with Phil Trinder, Jeremy Singer, and Adrian Ravi Kishore Ramsingh.
An existing smart campus application was developed using \gls{MTASK} and quantitatively and qualitatively compared to the original application that was developed using a traditional \gls{IOT} stack \citep{lubbers_tiered_2020}.
-This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK}, and \gls{MTASK} \citep{lubbers_could_2023}.
+This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK}, and \gls{MTASK} \citep{lubbers_could_2023} (see \cref{chp:smart_campus}).
Currently, power efficiency behaviour of traditional versus \gls{TOP} \gls{IOT} stacks is being compared as well adding a FreeRTOS, and an Elixir implementation to the mix as well.
\input{subfilepostamble}
repositories / phd-thesis.git / blobdiff