X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=arch.itasks.tex;fp=arch.itasks.tex;h=b8f4b089bffbc02ef5ad1a384e7bf3070db7414a;hb=f9f65d0883aeab3d3913c7cfb29def4c12df994e;hp=5ef0e6d36cfc62343c66fef8e9abd22d5e1d5a00;hpb=6c5e9431ef2ab0836e365dbca58a79d7625ac6af;p=msc-thesis1617.git

diff --git a/arch.itasks.tex b/arch.itasks.tex
index 5ef0e6d..b8f4b08 100644
--- a/arch.itasks.tex
+++ b/arch.itasks.tex
@@ -7,7 +7,7 @@ devices and view the state of the system.
 
 \subsection{Device Storage}
 Everything that a device encompasses is stored in the \CI{MTaskDevice} record
-type which is in turn stored in a \gls{SDS}. This includes management for the
+type which is in turn stored in an \gls{SDS}. This includes management for the
 \glspl{SDS} and \glspl{Task} stored on the device. The \CI{MTaskDevice}
 definition is shown in Listing~\ref{lst:mtaskdevice} accompanied with the
 necessary classes and sub types. Devices added to the system must be reachable
@@ -80,7 +80,6 @@ This has the implication that the server and the client can get out of sync.
 However, this is by design and well documented. In the current system, an
 \gls{SDS} can only reside on a single device.
 
-% TODO
 % Single share per share
 There are several possible approaches for storing \glspl{SDS} on the server
 each with their own level of control. A possible way is to --- in the device
@@ -93,13 +92,13 @@ on the device. Accessing the \gls{SDS} happens by calling the \CI{get},
 \CI{set} and \CI{upd} functions directory on the actual \gls{SDS}.
 
 % Single share per device
-Another approach would be to have reference to a \gls{SDS} containing a table
-of \gls{SDS} values per device. This approach poses the same orphan problem as
-before. Accessing a single \gls{SDS} on the device happens by calling the
+Another approach would be to have reference to an \gls{SDS} containing a table
+of \gls{SDS} values per device. This approach suffers the same orphan problem
+as before. Accessing a single \gls{SDS} on the device happens by calling the
 \CI{get}, \CI{set} and \CI{upd} functions on the actual table \gls{SDS} with an
-applied \CI{mapReadWrite}. Using parametric lenses can circumvent problem of
-watchers getting notified for other shares that are written. Error handling is
-better than the previously mentioned approach because a \gls{SDS} can know
+applied \CI{mapReadWrite}. Using parametric lenses can circumvent the problem
+of watchers getting notified for other shares that are written. Error handling
+is better than the previously mentioned approach because an \gls{SDS} can know
 whether the \gls{SDS} has really gone because it will not be available anymore
 in the table. It still does not know whether the device is still available.
 
@@ -117,8 +116,8 @@ high frequency.
 The type for the parametric lens of the \gls{SDS} containing all devices is
 \CI{Maybe (MTaskDevice, Int)}. There are several levels of abstraction that
 have to be introduced. First, the \gls{SDS} responsible for storing the entire
-list of devices is called the global \gls{SDS}. Secondly, a \gls{SDS} can focus
-on a single device, such \glspl{SDS} are called local \glspl{SDS}. Finally, a
+list of devices is called the global \gls{SDS}. Secondly, an \gls{SDS} can focus
+on a single device, such \glspl{SDS} are called local \glspl{SDS}. Finally, an
 \gls{SDS} can focus on a single \gls{SDS} on a single device. These \glspl{SDS}
 are called share \glspl{SDS}. Using parametric lenses, the notifications can be
 directed to only the watchers interested. Moreover, using parametric lenses,