mtaskext.sdssem.tex

   1 \Gls{mTask}-\glspl{SDS} on a client are available on the server as in the form
   2 of regular \gls{iTasks}-\glspl{SDS}. However, the same freedom that an
   3 \gls{SDS} has in the \gls{iTasks}-system is not given for \glspl{SDS} that
   4 reside on the client. Not all types are suitable to be located on a client,
   5 simply because it needs to be representable on clients. Moreover, \glspl{SDS}
   6 behave a little different in an \gls{mTask} device compared to in the
   7 \gls{iTasks} system. In an \gls{iTasks} system, when the \gls{SDS} is updated,
   8 a broadcast to all watching \glspl{Task} in the system is made to notify them
   9 of the update. \glspl{SDS} can update often and the update might not be the
  10 final value it will get. Implementing the same functionality on the \gls{mTask}
  11 client would result in a lot of expensive unneeded bandwidth usage.  Therefore
  12 a device must publish the \gls{SDS} explicitly to save bandwidth.
  13
  14 To add this functionality, the \CI{sds} class could be extended. However, this
  15 would result in having to update all existing views that use the \CI{sds}
  16 class. Therefore, an extra class is added that contains the extra
  17 functionality. Programmers can choose to implement it for existing views in the
  18 future but are not obliged to. The publication function has the following
  19 signature:
  20 \begin{lstlisting}[caption={The \texttt{sdspub} class}]
  21 class sdspub v where
  22   pub :: (v t Upd) -> v t Expr | type t
  23 \end{lstlisting}