small introduction update

diff --git a/abstract.tex b/abstract.tex
index 5030daf..c4bb5e4 100644 (file)
--- a/abstract.tex
+++ b/abstract.tex
@@ -1,7 +1,7 @@
 This thesis presents a way to connect small \gls{IoT} devices with high level
 \gls{TOP} implementations languages. It shows how a new frontend for the class
-based shallowly \glspl{EDSL} called \gls{mTask} written in \gls{Clean}
-can be used to compile \gls{IoT}-tasks on the fly and send them to the device
+based shallowly \gls{EDSL} called \gls{mTask} written in \gls{Clean}
+can be used to compile \gls{IoT}-tasks on the fly and send them to devices
 as interpretable bytecode. All of this adheres to the \gls{TOP} philosophy
 where familiar concepts such as \glspl{SDS} and task-combinators are available
 at ease.

diff --git a/introduction.tex b/introduction.tex
index 6ec3e65..c2ee7bc 100644 (file)
--- a/introduction.tex
+++ b/introduction.tex
@@ -1,42 +1,43 @@
 \section{Introduction}
 The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a
-high abstraction level of real life workflow tasks. Through an \gls{EDSL} that
-programmers can model workflow tasks. The system will then generate a
-multi-user web service. This web service can be accessed through a browser and
-used to complete these \glspl{Task}. Familiar workflow patterns like sequence,
-parallel and conditional tasks can be modelled. From the \gls{Task} description
-the system will generate an multi-user web application for real life tasks.
+high abstraction level for real life workflow tasks. These workflow tasks can be
+described through an \gls{EDSL} and modeled as \glspl{Task}
+From the specification the system will then generate a multi-user web service.
+This web service can be accessed through a browser and used to complete these
+\glspl{Task}. Familiar workflow patterns like sequence, parallel and
+conditional tasks can be modelled using combinators.
 
-\gls{iTasks} has been shown to be useful in many fields of operation such as incident
-management~\cite{lijnse_top_2013}. Interfaces are automatically generated for
-the types of data which makes rapid development possible. However, while the
-tasks in the \gls{iTasks} system model after real life workflow tasks the
-modelling is very high level. It is difficult to connect actual tasks to the
-real tasks and let them interact. A lot of the actual tasks can be
-\emph{performed} by small \gls{IoT} devices. Nevertheless, adding such devices
-to the current system is difficult to say the least as it was not designed to
-cope with these devices. 
+\gls{iTasks} has been shown to be useful in many fields of operation such as
+incident management~\cite{lijnse_top_2013}. Interfaces are automatically
+generated for the types of data which makes rapid development possible.
+However, while the tasks in the \gls{iTasks} system model after real life
+workflow tasks the modelling is very high level. It is difficult to connect
+actual tasks to the real tasks and let them interact. A lot of the actual tasks
+can be \emph{performed} by small \gls{IoT} devices. Nevertheless, adding such
+devices to the current system is difficult to say the least as it was not
+designed to cope with these devices. 
 
 In the current system such adapters, in principle, can be written as 
 \glspl{SDS}\footnote{Similar as to resources such as time are available in
 the current \gls{iTasks} implementation} but this requires a very specific
-adapter to be written for every device and functionality. Moreover, this does
-not allow you to build in logic into the device. A lot of the small \gls{IoT}
-devices have limited processing power but can still contain decision making.
-Oortgiese et al.\ lifted \gls{iTasks} from a single server model to a
+adapter to be written for every device and functionality. However, this forces
+a fixed logic in the device that is set at compile time. A lot of the small
+\gls{IoT} devices have limited processing power but can still contain decision
+making. Oortgiese et al.\ lifted \gls{iTasks} from a single server model to a
 distributed server architecture~\cite{oortgiese_distributed_2017} that is also
-runnable on smaller devices like \acrshort{ARM}. However, this is limited to
-fairly high performance devices that are equipped with high speed communication
-lines. Devices in \gls{IoT} often only have \gls{LTN} communication with low
-bandwidth and a very limited amount of processing power and are therefore not
-suitable to run an entire \gls{iTasks} core.
+runnable on smaller devices like \acrshort{ARM} devices. However, this is
+limited to fairly high performance devices that are equipped with high speed
+communication channels. Devices in \gls{IoT} often only have \gls{LTN}
+communication with low bandwidth and a very limited amount of processing power
+and are therefore not suitable to run an entire \gls{iTasks} core.
 
 \glspl{mTask} will bridge this gap by introducing a new communication protocol,
-device server application and \glspl{Task} synchronizing the formers.
+device application and \glspl{Task} synchronizing the formers.
 The system can run on devices as small as Arduino microcontrollers and
 operates via the same paradigms and patterns as regular \glspl{Task}.
 \glspl{mTask} can run small imperative programs written in a \gls{EDSL} and
-have access to \glspl{SDS}.
+have access to \glspl{SDS}. In this way \glspl{Task} can be sent to the device
+at runtime and information can be exchanged.
 
 \section{Document structure}
 The structure of the thesis is as follows.