From 9867b4984c4556369979228c498c848baeedf8c3 Mon Sep 17 00:00:00 2001 From: Geoffrey Challen Date: Tue, 23 Dec 2014 12:38:25 -0500 Subject: [PATCH] Back to six pages. --- .ispell_english | 11 +++++++++++ conclusion.tex | 3 +-- discussion.tex | 52 +++++++++++++++++++++++----------------------------- references.bib | 2 +- related.tex | 38 ++++++++++++++------------------------ usage.tex | 43 ++++--------------------------------------- 6 files changed, 54 insertions(+), 95 deletions(-) diff --git a/.ispell_english b/.ispell_english index 09f14aa..c8f26a9 100644 --- a/.ispell_english +++ b/.ispell_english @@ -1,12 +1,23 @@ 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 diff --git a/conclusion.tex b/conclusion.tex index 27ea3ea..d0ad725 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -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} diff --git a/discussion.tex b/discussion.tex index 96eac3e..20a449a 100644 --- a/discussion.tex +++ b/discussion.tex @@ -1,42 +1,36 @@ \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. diff --git a/references.bib b/references.bib index 5efb1c9..a59aae9 100644 --- a/references.bib +++ b/references.bib @@ -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}, } diff --git a/related.tex b/related.tex index 1d3b127..1c82e4a 100644 --- a/related.tex +++ b/related.tex @@ -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. diff --git a/usage.tex b/usage.tex index f7a0236..2c3b59d 100644 --- a/usage.tex +++ b/usage.tex @@ -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} -- libgit2 0.22.2