Back to six pages.

Geoffrey Challen
1 parent 4e09b796
Showing 6 changed files with 54 additions and 95 deletions
.ispell_english
conclusion.tex
discussion.tex
references.bib
related.tex
usage.tex
 Android
+API
 APIs
 app
 apps
+codebase
 Endgames
 JSON
+logcat
+Navjack
+Navjack's
 outsourced
+PhoneLab
+PocketParker
 pre
+refactored
 runtime's
 smartphone
+smartphone's
 smartphones
+testbed
+USB
 Wifi
@@ -5,8 +5,7 @@ To conclude, we have described the \texttt{maybe} statement: a new language
 construct allowing developers to express structured uncertainty at
 development time and for that uncertainty to be resolved through later
 testing and adaptation. We are in the process of building a prototype of the
-\texttt{maybe} system for Android smartphones and are excited to share
-results from our experiences.
+\texttt{maybe} system for Android smartphones.
 \section*{Acknowledgments}
 \section{Discussion}
 \label{sec-discussion}
-We have yet to determine how well programmers will be able to use the
-\texttt{maybe} statement. Structurally \texttt{maybe} statements are similar
-to the ubiquitous \texttt{if-else} construct in that at the bottom of the
-statement the programmer may not be sure which block was executed. However,
-while with \texttt{if-else} blocks it can be determined which block was
-executed by examining the branch conditions, \texttt{maybe} statements
-require developers to record which alternative was executed if downstream
-code depends on the decision. To coordinate the adaptation of multiple code
-paths a single \texttt{maybe} variable---such as the policy string in
-Figure~\ref{fig-maybeexamples}---can be used to control multiple
-\texttt{if-else} statements.
+We have yet to determine how natural programmers will find the \texttt{maybe}
+statement. Encouragingly, \texttt{maybe} statements are similar to the
+ubiquitous \texttt{if-else} statement, and in many cases can be used to
+directly replace \texttt{if-else} statements that attempt runtime adaptation.
+To coordinate the adaptation of multiple code paths a single \texttt{maybe}
+variable---such as the policy string in Figure~\ref{fig-maybeexamples}---can
+be used to control multiple \texttt{if-else} statements.
 While \texttt{maybe} is a powerful programming tool, it is important that it
 be used sparingly. If objective dependencies exist between \texttt{maybe}
 statements, the overall configuration space may expand exponentially,
-complicating the process of determining the best alternatives described in
-Section~\ref{sec-certainty}. (A similar problem exists with nested
-\texttt{maybe} statements.) Compile-time analysis may be required to detect
-dependencies between \texttt{maybe} statements and ensure that downstream
-optimization remains feasible.
+complicating post-deployment adaptation process. Compile-time analysis may be
+required to detect dependencies between \texttt{maybe} statements and
+encourage programmers to limit their use of \texttt{maybe} if to ensure that
+downstream optimization remains feasible.
-One important place where \texttt{maybe} should not be used is when
-adaptation is not app-specific and can be refactored into a library serving
-multiple apps. As an example, an app should not use \texttt{maybe} to decide
-which network interface to use when attempting to achieve a common objective,
-such as maximizing throughput. This choice would be better refactored into a
-dedicated library, which might use its own internal \texttt{maybe}
-statements. Not only is the resulting codebase smaller, but the total number
-of \texttt{maybe} statements that the system has to determine how to handle
-is reduced.
+\texttt{maybe} statements should not be used when adaptation is not
+app-specific and can be refactored into a library. As an example, an app
+should not use \texttt{maybe} to decide which network interface to use when
+attempting to achieve a common objective, such as maximizing throughput. This
+choice would be better refactored into a dedicated library, which might use
+its own internal \texttt{maybe} statements. Not only is the resulting
+codebase smaller, but the total number of \texttt{maybe} statements that the
+system has to test is reduced.
 However, the \texttt{maybe} statement represents a fundamentally different
-approach from previously attempts to enable runtime adaptation that relied on
-libraries. As a code organization stategy, the benefits that libraries provide
-in terms of reduced duplication and more powerful interfaces are orthogonal and
-complementary to the \texttt{maybe} statement. That said, a large amount of
+approach from attempts to enable runtime adaptation that rely on libraries.
+As a code organization strategy, the benefits that libraries provide in terms
+of reduced duplication and more powerful interfaces are orthogonal and
+complementary to the \texttt{maybe} statement. However, a large amount of
 code including adaptation logic remains app specific and cannot be refactored
 into a library.
@@ -60,7 +60,7 @@
 Title = {{The Mote is Dead. Long Live the Discarded Smartphone!}},
 Author = {Geoffrey Challen and Scott Haseley and Anudipa Maiti and Anand
 Nandugudi and Guru Prasad and Mukta Puri and Junfei Wang},
- Month = {February},
+ Month = {Feb.},
 Year = {2014},
 }
@@ -4,25 +4,16 @@
 New systems such as EnFrame~\cite{arxiv13-enframe} reflect growing interest
 in managing uncertainty at the language level. EnFrame focuses on enabling
 programming with uncertain data, rather than the runtime adaptation enabled
-by the \texttt{maybe} statement. Specifically a variable controlled by a
-\texttt{maybe} statement has a single value that is being evaluated at any
-given time, while EnFrame allows that same variable to have a distribution of
-values reflecting error or other forms of uncertainty about what it's true
-value should be.
+by \texttt{maybe}.
-Aspect oriented programming (AOP)~\cite{aop} was proposed by Kiczales et al.
-as a programming paradigm geared toward increasing modularity through the
-separation of cross-cutting concerns in software. The programmer can express
-cross cutting concerns in stand alone modules, or aspects. Aspects are
+Aspect oriented programming (AOP)~\cite{aop} aims to increase modularity
+through the separation of cross-cutting concerns. The programmer can express
+cross-cutting concerns in stand alone modules, or aspects. Aspects are
 composed of advice, which specifies a computation to be performed as well as
 points in the program at which that computation should be performed.
-Abstractly, aspects provide an interesting framework on top of which we could
-realize \texttt{maybe} blocks. At runtime, different aspects could be weaved
-depending on the framework decisions. Aspects would also allow ``chained''
-\texttt{maybe} blocks through the use of multiple join points and point-cuts.
-Fundamentally, however, the goals of AOP and the \texttt{maybe} statement
-differ, with AOP focusing on modularity and \texttt{maybe} focused on
-increasing runtime flexibility in the face of uncertainty.
+Fundamentally, the goals of AOP and the \texttt{maybe} statement differ, with
+AOP focusing on modularity and \texttt{maybe} focused on increasing runtime
+flexibility in the face of uncertainty.
 \texttt{maybe} shares similaries with language-based approaches to managing
 energy consumption in wireless sensor networks such as
@@ -33,11 +24,10 @@ which energy states are appropriate as the \texttt{maybe} system would do.
 \texttt{maybe} can also enable adaptation driven by goals other than energy
 management.
-Enabling more adaptive mobile systems is a challenge with a long history dating
-back to work on systems such as Odyssey~\cite{odyssey-sosp97}. However, a
-taxonomy of approaches to enabling adaptation on early mobile
-systems~\cite{badrinath2000conceptual} reflects the focus of early efforts on
-incorporating adaptation into libraries that could be used by multiple apps. As
-we have pointed out previously, while adaptation libraries are useful,
-\texttt{maybe} statements can make them more powerful by allowing programmers
-to express uncertainty.
+Attempts to enable more adaptive mobile systems date back to systems such as
+Odyssey~\cite{odyssey-sosp97}. However, a taxonomy of approaches to enabling
+adaptation on early mobile systems~\cite{badrinath2000conceptual} reflects
+the focus of early efforts on incorporating adaptation into libraries that
+could be used by multiple apps. As we have pointed out previously, while
+adaptation libraries are useful, \texttt{maybe} statements can make them more
+powerful by allowing programmers to express uncertainty.
@@ -36,7 +36,7 @@ each user enjoys whichever approach is most effective for them.
 \subsection{\texttt{\large PhoneLab} Conductor}
 \PhoneLab{} is a large scale smartphone platform testbed at the University at
-Buffalo~\cite{phonelab-sensemine13,phonelab-url}. We leverage the Android
+Buffalo~\cite{phonelab-sensemine13}. We leverage the Android
 \texttt{logcat} subsystem as a data collection mechanism---experiment apps
 write their data into a system-wide log buffer and we collect and upload this
 data on their behalf.
@@ -58,7 +58,7 @@ allows us to control aspects of program behavior such as the amount of
 storage space we use on each device for logs, how often we check for updates,
 and how to decide whether to upload data. Several of these features have
 proven essential after deployment---for example, when an upload policy that
-worked previously abruptly stopped working on a newer Androiod version.
+worked previously abruptly stopped working on a newer Android version.
 Development of this app would have been considerably easier using
 \texttt{maybe}, which could automate the process of pushing policies to
 clients in an energy-efficient way, and enable per-user goal-driven
@@ -68,9 +68,9 @@ adaptation.
 \subsection{Navjack Sensing Platform}
 The Navjack project is exploring hijacking in-car navigation devices built
-from repurposed smartphones~\cite{sustain-hotmobile14} and deployed in
+from recycled smartphones~\cite{sustain-hotmobile14} and deployed in
 personal vehicles to enable city-scale sensing. Volunteers install a device
-that acts as a dedicated navigational aid and car performance monitor but
+that acts as a dedicated navigation aid and car performance monitor but
 also continuously collects sensor data, utilizing the car's battery for
 power, the car's driver for maintenance, and inexpensive machine-to-machine
 (M2M) data plans for telemetry.
@@ -91,38 +91,3 @@ space that can potentially get quite large, and so it may provide a good
 chance to evaluate both our ability to perform pre-deployment simulations to
 reduce the state space and the success of post-deployment clustering
 techniques to identify salient user differences.
-
-\subsection{Android Platform Services}
-
-Earlier, we noted that that app developers should not use \texttt{maybe} to
-make decisions that are best left to libraries and platform services. However, 
-those same
-libraries and platform services can themselves use \texttt{maybe} to enable
-post-deployment testing and adaptation. We are particularly interested in how
-\texttt{maybe} can be used within the Android platform itself wherever
-structured uncertainty must be expressed.
-
-One use case is determining whether to use Wifi or cellular network. While this is
-a hot topic in current mobile systems research~\cite{shen2008cost}, the approaches
-that are currently being tested may struggle to adapt to many of the
-variable that the \texttt{maybe} system incorporates and arrive at an
-effective per-user approach. A similar example is optimizing the state of
-GPS. With three modes already present---``High accuracy'', ``Battery saving'', and
-``Device only'', the choice may need to be adapted both to app usage and more
-user- or device-specific factors. \texttt{maybe} allows post-deployment
-testing of a variety of different approaches to make this runtime decision.
-
-\begin{comment}
-
-Stretching this idea further, what if the developer didn't have to think
-about cache or object availability? The language itself could determine which
-block to run based on the semantics of the \texttt{maybe} case definition.
-For instance, in the \texttt{android.emoji.EmojiFactory} class, there is a
-method to get an eomji via its Unicode PUA (Private Use Area). To do this,
-the emoji is either grabbed from a platform-level cache or is created then
-written to the cache then returned. With \texttt{maybe}, the developer could
-have two blocks one for the cache being empty for the PUA and one where an
-object exists. Now, the developer doesn't need to think about the
-possibilities of cache-state, but instead can move on to other functionality.
-
-\end{comment}