\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
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
\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.
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,
repositories / msc-thesis1617.git / blobdiff