mtaskext.sdsprop.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 and serializable for
   6 communication. Moreover, \glspl{SDS} behave a little different in an
   7 \gls{mTask} device compared to in the \gls{iTasks} system. In an \gls{iTasks}
   8 system, when the \gls{SDS} is updated, a broadcast to all watching \glspl{Task}
   9 in the system is made to notify them of the update.  \glspl{SDS} can update
  10 often and the update might not be the final value it will get. Implementing the
  11 same functionality on the \gls{mTask} client would result in a lot of expensive
  12 unneeded bandwidth usage. Therefore a device must publish the \gls{SDS}
  13 explicitly to save bandwidth. Note that this means that the \gls{SDS} value on
  14 the device can be different compared to the value of the same \gls{SDS} on the
  15 server.
  16
  17 To add this functionality, the \CI{sds} class could be extended. However, this
  18 would result in having to update all existing views that use the \CI{sds}
  19 class. Therefore, an extra class is added that contains the extra
  20 functionality. Programmers can choose to implement it for existing views in the
  21 future but are not obliged to. The publication function has the following
  22 signature:
  23 \begin{lstlisting}[language=Clean,caption={The \texttt{sdspub} class}]
  24 class sdspub v where
  25   pub :: (v t Upd) -> v t Expr | type t
  26 \end{lstlisting}
  27
  28 \glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always attached to a \CI{Main}
  29 component. Thus, they are not usable in the \gls{Task} domain. To solve this,
  30 the \glspl{SDS} found in the \CI{Main} object are instantiated as real
  31 \gls{SDS} in the server. This poses a problem of naming because
  32 \glspl{SDS} in the \gls{mTask}-\gls{EDSL} are always anonymous at runtime. There
  33 is no way of labeling it since it is not a real entity, it is just a function.
  34 When \glspl{SDS} is instantiated and communicated with the device, they must be
  35 retrievable and identifiable. Internally this identification happens through
  36 numeric identifiers, but this is handy for programmers since.
  37 Therefore, an added class named \CI{namedsds} is added that provides the exact
  38 same functionality as the \gls{SDS} class but adds a \CI{String} parameter that
  39 can later be used to identify an \gls{SDS} in the bag of instantiated
  40 \glspl{SDS} that result from compilation. The types for this class are shown in
  41 Listing~\ref{lst:namedsds}. Again, an example is added for illustration.
  42 Retrieving the \gls{SDS} after compilation is shown in
  43 Section~\ref{sec:archexamples}.
  44
  45 \begin{lstlisting}[language=Clean,label={lst:namedsds},%
  46         caption={The \texttt{namedsds} class}]
  47 class namedsds v where
  48         namedsds :: ((v t Upd) -> In (Named t String) (Main (v c s))) -> (Main (v c s)) | ...
  49 :: Named a b = Named infix 1 a b
  50
  51 sdsExample :: Main (v Int Stmt)
  52 sdsExample = sds \x.0 Named "xvalue" In
  53         {main= x =. x +. lit 42 }
  54 \end{lstlisting}