comments ms

[phd-thesis.git] / tvt / tvt.tex

diff --git a/tvt/tvt.tex b/tvt/tvt.tex
index 085acc6..efae48e 100644 (file)
--- a/tvt/tvt.tex
+++ b/tvt/tvt.tex
@@ -32,13 +32,13 @@ Conventional \gls{IOT} software architectures require the development of separat
 \begin{enumerate*}
        \item Interoperating components in multiple languages and paradigms increases the developer's cognitive load who must simultaneously think in multiple languages and paradigms, i.e.\ manage significant semantic friction.
        \item The developer must correctly interoperate the components, e.g.\ adhere to the \gls{API} or communication protocols between components.
-       \item To ensure correctness the developer must maintain type safety across a range of very different languages and diverse type systems.\todo[inline]{what do you mean by type safety here precisely? how can that happend if non type safe languages are in the mix}
+       \item To ensure correctness the developer must maintain type safety across a range of very different languages and diverse type systems.
        \item The developer must deal with the potentially diverse failure modes of each component, and of component interoperation.
 \end{enumerate*}
 
 A radical alternative development paradigm uses a single \emph{tierless} language that synthesises all components\slash{}tiers in the software stack. There are established \emph{tierless} languages for web stacks, e.g.\ Links \citep{cooper2006links} or Hop \citep{serrano2006hop}.
 In a tierless language the developer writes the application as a single program. The code for different tiers is simultaneously checked by the compiler, and compiled to the required component languages. For example, Links compiles to HTML and JavaScript for the web client and to SQL on the server to interact with the database system. Tierless languages for \gls{IOT} stacks are more recent and less common, examples include
-Potato \citep{troyer_building_2018} and \gls{CLEAN} with \imtask{} \citep{lubbers_interpreting_2019}.
+Potato \citep{troyer_building_2018}, and \gls{CLEAN} with \imtask{} \citep{lubbers_interpreting_2019}.
 
 \Gls{IOT} sensor nodes may be microcontrollers with very limited compute resources, or supersensors: resource-rich single board computers like a Raspberry Pi. A tierless language may target either class of sensor node, and microcontrollers are the more demanding target due to the limited resources, e.g.\ small memory, executing on bare metal, \etc.
 
@@ -202,8 +202,6 @@ Only a small fraction of these systems are described in the academic literature,
 \label{sec_t4t:characteristics}
 
 This study compares a pair of tierless \gls{IOT} languages with conventional tiered \gls{PYTHON} \gls{IOT} software. \Citask{} and \cimtask{} represent a specific set of tierless language design decisions, however many alternative designs are available. Crucially the limitations of the tierless \gls{CLEAN} languages, e.g.\ that they currently provide limited security, should not be seen as limitations of tierless technologies in general. This section briefly outlines key design decisions for tierless \gls{IOT} languages, discusses alternative designs, and describes the \gls{CLEAN} designs. The \gls{CLEAN} designs are illustrated in the examples in the following section.
-\todo{again, here it would be good to have a general definition of tierless, and then describe what the possible design choices are, and where in the space iTask/mTask fits}
-
 
 \subsubsection{Tier splitting and placement}
 A key challenge for a tierless language is to determine which parts of the program correspond to a particular tier and hence should be executed by a specific component on a specific host.