X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=results.arch.tex;h=b6b0b3d4309c6bcafda04579f8eb80067d0830ee;hb=a4d108b9046bfd1d94e8b986a00c00090391d7b6;hp=b408592f0c9577e0976c87dc3e41738da0546428;hpb=7236429d2968225cf537aa679a02e49232400ef4;p=msc-thesis1617.git diff --git a/results.arch.tex b/results.arch.tex index b408592..b6b0b3d 100644 --- a/results.arch.tex +++ b/results.arch.tex @@ -1,13 +1,13 @@ The goal of the system as a whole is to offer a framework of functions with which an \gls{iTasks}-system can add, change and remove devices at runtime. -Moreover, the \gls{iTasks}-system can send \glspl{mTask} --- compiled at -runtime to bytecode by the \gls{mTask}-view --- to the device. The device runs -an interpreter which can execute the \gls{Task}'s bytecode. Device profiles -should be persistent during reboots of the \gls{iTasks}-system. The methods of -interacting with \glspl{mTask} should be analogous to interacting with -\gls{iTasks}-\glspl{Task}. This means that programmers can access the -\glspl{SDS} made for a device in the same way as regular \glspl{SDS} and they -can execute \gls{mTask}-\glspl{Task} as if they where normal +Moreover, the \gls{iTasks}-system can send \gls{mTask}-\glspl{Task} --- +compiled at runtime to bytecode by the \gls{mTask}-view --- to the device. The +device runs an interpreter which can execute the \gls{Task}'s bytecode. Device +profiles should be persistent during reboots of the \gls{iTasks}-system. The +methods of interacting with \gls{mTask}-\gls{Task} should be analogous to +interacting with \gls{iTasks}-\glspl{Task}. This means that programmers can +access the \glspl{SDS} made for a device in the same way as regular \glspl{SDS} +and they can execute \gls{mTask}-\glspl{Task} as if they where normal \gls{iTasks}-\glspl{Task}. The following terms will be used throughout the following chapter: @@ -60,7 +60,7 @@ the device software. development board. \item Microcontrollers which are programmable in the \gls{Arduino} \gls{IDE} connected via serial communication or via \gls{TCP} over WiFi or - ethernet. + Ethernet. This does not only include \gls{Arduino} compatible boards but also other boards capable of running \gls{Arduino} code. A port of the @@ -210,7 +210,7 @@ peripheral availability, the memory available for storing \glspl{Task} and \glspl{SDS} and the size of the stack. \begin{lstlisting}[label={lst:devicespec}, - caption={Device specification for \glspl{mTask}}] + caption={Device specification for \gls{mTask}-\glspl{Task}}] :: MTaskDeviceSpec = { haveLed :: Bool , haveLCD :: Bool @@ -286,7 +286,7 @@ format are explained in the following section. \subsection{Shares} The system keeps track of the \glspl{SDS} stored on the client in a big \gls{SDS} containing a list of devices. Client-\glspl{SDS} -can be stored on one device at the same time. This means that if a \gls{SDS} +can be stored on one device at the same time. This means that if an \gls{SDS} updates, everyone watching it will be notified. This would result in a lot of notifications that are not meant for the watcher. Moreover, when a client updates the \gls{SDS} this is processed by the connection handler and results @@ -305,7 +305,7 @@ Improved on this, a single \gls{iTasks}-\gls{SDS} can be created for every devices that stores the respective \glspl{SDS}. Using the \CI{mapReadWrite} functions, a single \gls{SDS} per device can be created as a lens that allows mapping on a single client-\gls{SDS}. However, this approach still requires -\glspl{Task} listening to the \gls{SDS} and when a \gls{SDS} is written, +\glspl{Task} listening to the \gls{SDS} and when an \gls{SDS} is written, everyone is notified, even if the \gls{Task} only uses the value of a single different \gls{SDS}. @@ -314,7 +314,7 @@ Finally, the current approach --- a single \gls{SDS} for the entire system \CI{mapReadWrite} can be used but it suffers from the same problem as mentioned before. Moreover, a \gls{Task} still has to watch the \gls{SDS} and communicate the client-\gls{SDS} updates to the actual device. Both of these problems can -be solved by using a tailor made share that heavily depends on parametric +be solved by using a tailor made \gls{SDS} that heavily depends on parametric lenses. \subsection{Parametric Lenses} @@ -327,8 +327,8 @@ implementation of the real \gls{SDS} is given in Listing~\ref{lst:actualdev}. The \gls{SDS} is a lens on an actual \gls{SDS} that writes to a file or memory. Reading the \gls{SDS} is nothing more than reading the real \gls{SDS}. Writing the \gls{SDS} is a little bit more involved. If the write operation originated -from a \gls{SDS} focussed on a single client-\gls{SDS}, the write action must -also be relayed to the actual device. If the write originated from a \gls{SDS} +from an \gls{SDS} focussed on a single client-\gls{SDS}, the write action must +also be relayed to the actual device. If the write originated from an \gls{SDS} focussed the devices or on one device only, nothing needs to be done. The notification predicate determines whether a watcher gets a notification update. @@ -394,10 +394,10 @@ deviceShare d = mapReadWriteError $ sdsFocus (Just (d, -1)) deviceStore \end{lstlisting} -\subsubsection{Local-share specific \glspl{SDS}} +\subsubsection{Local-\gls{SDS} specific \glspl{SDS}} A single \gls{SDS} on a single device can be accessed using the \CI{shareShare} -function. This function focusses the real big \gls{SDS} on a single share and -uses the \CI{mapReadWrite} functions to serve the correct part of the +function. This function focusses the real big \gls{SDS} on a single \gls{SDS} +and uses the \CI{mapReadWrite} functions to serve the correct part of the information. \begin{lstlisting}[caption={Local \gls{SDS}}] @@ -578,11 +578,12 @@ interface is shown in Figure~\ref{lst:manage}. The left sidebar of the interface shows the list of example \glspl{Task} that are present in the system. When clicking a \gls{Task}, a dialog opens in which a device can be selected to send the \gls{Task} to. The dialog might contain user specified -variables. All example \glspl{mTask} are of the type \CI{Task (Main (ByteCode -() Stmt))} and can thus ask for user input first if needed for parameterized -\glspl{mTask}. The bottom panel shows the device information. In this panel, -the devices can be created and modified. Moreover, this panel allows the user -to reconnect with a device after a restart of the server application. +variables. All example \gls{mTask}-\glspl{Task} are of the type \CI{Task (Main +(ByteCode () Stmt))} and can thus ask for user input first if needed for +parameterized \gls{mTask}-\glspl{Task}. The bottom panel shows the device +information. In this panel, the devices can be created and modified. Moreover, +this panel allows the user to reconnect with a device after a restart of the +server application. \begin{figure}[H] \centering @@ -591,7 +592,7 @@ to reconnect with a device after a restart of the server application. \end{figure} \section[Lifting mTasks to iTasks-Tasks]% - {Lifting \glspl{mTask} to \gls{iTasks}-\glspl{Task}} + {Lifting \gls{mTask}-\glspl{Task} to \gls{iTasks}-\glspl{Task}} If the user does not want to know where and when a \gls{mTask} is actually executed and is just interested in the results it can lift the \gls{mTask} to an \gls{iTasks}-\glspl{Task}. The function is called with a name, \gls{mTask}, @@ -608,4 +609,4 @@ where \end{lstlisting} \section{Examples} -\todo{example program (demo)} +Here comes a description of the demo program.