X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=results.mtask.tex;h=591280138d27f0462f07989e74178435703cf9f8;hb=d5af27e20c1e3db773a44439ad548e1682113d69;hp=a70243271f5380226ebb01dbc22d51acbdbb4f57;hpb=0afef96572c804f8b5d7a2b0c6becf415c057496;p=msc-thesis1617.git

diff --git a/results.mtask.tex b/results.mtask.tex
index a702432..5912801 100644
--- a/results.mtask.tex
+++ b/results.mtask.tex
@@ -1,29 +1,65 @@
-Some functionality of the original \gls{mTask}-\gls{EDSL} will not be used in
-this extension \gls{EDSL}. Conversely, some functionality needed was not
-available in the existing \gls{EDSL}. Due to the nature of class based shallow
-embedding this obstacle is very easy to solve. A type housing the \gls{EDSL}
-does not have to implement all the available classes. Moreover, classes can be
-added at will without interfering with the existing views.
+The \glspl{Task} suitable for a client are called \glspl{mTask} and are written
+in the aforementioned \gls{mTask}-\gls{EDSL}. Some functionality of the
+original \gls{mTask}-\gls{EDSL} will not be used in this extension \gls{EDSL}.
+Conversely, some functionality needed was not available in the existing
+\gls{EDSL}. Due to the nature of class based shallow embedding this obstacle is
+very easy to solve. A type --- housing the \gls{EDSL} --- does not have to
+implement all the available classes. Moreover, classes can be added at will
+without interfering with the existing views.
 
 \section{Semantics}
-\subsection{\glspl{mTask}}
 The current \gls{mTask} engine for devices does not support \glspl{Task} in the
-sense that the \gls{C}-view it does. \glspl{Task} in the new system are are
-\CI{Main} objects with a program inside. A \gls{Task} runs periodically, on
-interrupt or one-shot. 
-\todo{elaborate}
+sense that the \gls{C}-view it does. \Glspl{Task} used with the \gls{C}-view
+are a main program that runs some \gls{Task}. \glspl{Task} in the new system
+are \CI{Main} objects with a program inside that does not contain \glspl{Task}
+but are a \gls{Task} as a whole. Sending a \gls{Task} always goes together with
+choosing a scheduling strategy. This strategy can be one of the following three
+strategies as reflected in the \CI{MTTask}.
+
+\begin{itemize}
+	\item\CI{OneShot}
+
+		\CI{OneShot} takes no parameters and means that the \gls{Task} will run
+		once and will then be removed automatically. This type of scheduling
+		could be usefull to for example retrieving sensor information on
+		request of a user.
+	\item\CI{OnInterval}
+
+		\CI{OnInterval} has as a parameter the number of milliseconds to wait
+		in between executions. \Glspl{Task} running with this scheduling method
+		are executed every fixed interval.
+	\item\CI{OnInterrupt}
+
+		The last scheduling method is running \glspl{Task} on a specific
+		interrupt. None of the current implementation implement this. However,
+		registering interrupts on for example the \gls{Arduino} is very
+		straightforward. Interrupt scheduling is usefull for \glspl{Task} that
+		have to react on a certain type of hardware event such as the press of
+		a button.
+\end{itemize}
 
 \subsection{\glspl{SDS}}
-\glspl{SDS} behave a little bit differently on an \gls{mTask} device than in
-the \gls{iTasks} system. In an \gls{iTasks} system, when the \gls{SDS} is
-updated, a broadcast to everyone in the system watching is made to notify them
-of an update. \glspl{SDS} on the device can update very often and the update
-might not be the final value it will get. Therefore a device must publish the
-\gls{SDS} explicitly to save bandwidth. This means that an extra function is
-added to the \CI{sds} class that adds the \CI{pub} function.
-\todo{elaborate}
-
-\section{Bytecode compilation}
+\Glspl{SDS} on a client are available on the server as well. However, the same
+freedom is not given on the \glspl{SDS} that reside on the client. Not all
+types are suitable to be located on a client. Moreover, \glspl{SDS} behave a
+little bit differently on an \gls{mTask} device than in the \gls{iTasks}
+system. In an \gls{iTasks} system, when the \gls{SDS} is updated, a broadcast
+to everyone in the system watching is made to notify them of an update.
+\glspl{SDS} on the device can update very often and the update might not be the
+final value it will get. Therefore a device must publish the \gls{SDS}
+explicitly to save bandwidth.
+
+To add this functionality, the \CI{sds} class could be extended. However, this
+would result in having to update all existing views that use the \CI{sds}
+class. Therefore, an extra class is added that contains the extra
+functionality. The existing views can choose to implement it in the future but
+are not obliged to. The publication function has the following signature:
+\begin{lstlisting}[caption={The \texttt{sdspub} class}]
+class sdspub v where
+  pub :: (v t Upd) -> v t Expr | type t
+\end{lstlisting}
+
+\section{Bytecode compilation}\label{sec:compiler}
 The \glspl{mTask} are sent to the device in bytecode and are saved in the
 memory of the device. To compile the \gls{EDSL} code to bytecode, a view is
 added to the \gls{mTask}-system called \CI{ByteCode}. As shown in
@@ -211,6 +247,7 @@ instance sds ByteCode where
 			>>= \(v In bdy)->modify (addSDS sds v)
 			>>| unBC (unMain bdy))
 		}
+instance sdspub ByteCode where
 	pub (BC x) = BC (censor (\[BCSdsFetch s]->[BCSdsPublish s]) x)
 
 addSDS sds v s = {s & sdss=[{sds & sdsval=BCValue v}:s.sdss]}