Merge pull request #10 from rvanheest/chapter-6

Chapters 5 and 6

report/0.0-acknowledgment.tex

@@ -2,9 +2,9 @@ \chapter*{Acknowledgment}
 
 I would like to thank Erik Meijer, my supervisor during this thesis project, for all his support, enthusiasm and hacker mentality. \textit{Erik, it was an honor to receive an email in May 2014, asking whether I was interested in doing my master thesis with you. From the beginning it was clear to both of us that Reactive Programming and Rx were a shared interest. It was great working with you on RxMobile, which has turned out to be very useful for this thesis. You really inspired me to have a hacker mentality, always keep trying to get things working and to never give up. I sincerely hope the completion of this thesis will not be the \code{onCompleted} event on the stream of our collaborations, but instead will just be the \code{onNext} event of a finished project on a much longer stream!}
 
-I also want to thank Georgios Gousios and Arie van Deursen for taking their time to be part of my thesis committee.
+I also want to thank Georgios Gousios and Arie van Deursen for taking their time to be part of my thesis committee and providing me with great feedback.
 
-Furthermore, I would like to thank my fellow students and friends at TU Delft, Eddy Bertoluzzo, Georgi Khomeriki, Mircea Voda, Mike de Waard and Lars Willems, who were doing their master theses in parallel with me. Thanks for the great time we had together at EWI-HB08.250 and the many discussions at the whiteboard and at Hangouts/Skype!
+Furthermore, I would like to thank my fellow students and friends at TU Delft, Eddy Bertoluzzo, Georgi Khomeriki, Mircea Voda, Mike de Waard and Lars Willems, who were doing their master theses in parallel with me. Thanks for the great time we had together at EWI-HB 08.250 and the many discussions at the whiteboard and at Hangouts/Skype!
 
 A special thanks to Michel van Heest, my brother, for creating all the diagrams in this thesis.
 

report/0.1-introduction.tex

@@ -19,7 +19,7 @@ \section*{Research Questions}
 \addcontentsline{toc}{section}{Research Questions}
 This thesis answers a number of questions that are related to reactive programming, overproducing sources in a reactive context and feedback control, which are listed and briefly introduced in this section.
 
-\subsubsection*{In what ways can a reactive program already be controlled to prevent overproduction?}
+\subsubsection*{In which ways can a reactive program already be controlled to prevent overproduction?}
 There are multiple solutions for controlling overproduction in the context of reactive programming. To understand these solutions, we first need to identify what various types of reactive programs exist and consider their mutual similarities and differences. Based on this we can identify which existing solution for controlling overproduction will or will not work for each particular type of reactive program. This analysis can further be used to create a better understanding of which type of reactive program is suited for the solution proposed in this thesis.
 
 \subsubsection*{How can we implement a \emph{reactive} feedback system that is composed of smaller parts?} 
@@ -28,8 +28,8 @@ \subsubsection*{How can we implement a \emph{reactive} feedback system that is c
 \subsubsection*{How can the overproduction problem be reduced to a feedback control problem?}
 In order to solve the problem of overproduction using feedback control, it is necessary to get out of the context of reactive programming and abstract this into more formal problems that can be solved using the principles control theory. Based on the feedback system that solves this control problem, a mapping can be created to the original problem of controlling overproduction in a reactive program.
 
-\subsubsection*{Can this new solution to overproduction be integrated into an existing API for reactive programming?}
-In order for this solution to be useful in practice, it is important to be able to integrate it with existing API's for reactive programming. To validate this, a clean API is needed that does not yet implement any solutions for overproduction by default. For this purpose we use the newly created RxMobile API \cite{RxMobile}.
+%\subsubsection*{Can this new solution to overproduction be integrated into an existing API for reactive programming?}
+%In order for this solution to be useful in practice, it is important to be able to integrate it with existing API's for reactive programming. To validate this, a clean API is needed that does not yet implement any solutions for overproduction by default. For this purpose we use the newly created RxMobile API \cite{RxMobile}.
 
 \section*{Outline}
 \addcontentsline{toc}{section}{Outline}

report/1.2-intro-to-rx.tex

@@ -1,4 +1,5 @@
 \section{Reactive Extensions}
+\label{sec:pure-rx-interfaces}
 There have been many attempts to fit the philosophy of reactive programming into frameworks, APIs and even languages \cite{ReactiveX, meijer2015-Dart, Reactive-Streams, Akka, Elm, RxMobile}. In this section, we will discuss some of the features of one of these libraries, namely Reactive Extensions (a.k.a. Rx). This project started at Microsoft with an implementation in C\# \cite{meijer2010-Observable} (Rx.Net), was later ported to Java, Scala, Groovy, Kotlin, JavaScript, Swift and many other languages by the open source community \cite{ReactiveX}. It is currently the standard library for programming in a reactive way.
 
 Unfortunately, these various translations have each been evolving in their own way, deviating from both the original implementation as well as each other. There are obvious minor changes such as operator names changing to conform particular language standards, but also behavior in various corner cases changed. Most remarkable however is that some implementations are not even purely `reactive' anymore \cite{meijer2014-Derivation}. Given these deviations from the original paradigm and the state of complexity of these implementations, we decided to use a reference implementation of the original Rx that has recently been written in Scala by Erik Meijer et al. called RxMobile \cite{RxMobile}, with the purpose of creating a light-weight implementation for mobile app development. The following discussion and derivation of the API will however apply to both Reactive Extensions and RxMobile and in this section we will therefore refer to both of them as `Rx'.

report/2.1-hot-cold-streams.tex

@@ -1,7 +1,7 @@
 \section{Hot and cold streams}
 Applying the definition of reactiveness by Benveniste and Berry \cite{berry1991-Reactive} to the Rx \obs, we can conclude that every \obs sequence starts with a source that emits values at its own pace. No matter which function is used for this (\code{apply}, \code{range}, \code{timer}, \code{interval}, etc.), ultimately they all are the result of the \code{Observable.create} function. This function lifts an arbitrary source into the \obs interface and treats its values like streaming data. The behavior that is exposed by the resulting stream can, however, differ from source to source.
 
-Sources like clocks, mouse moves or key presses start emitting regardless of any \obv being subscribed to the stream. When no one is listening, the data is simply discarded; when multiple \obv instances are subscribed, every one of them receives the same data at (approximately) the same time. In case an \obv subscribes at a later time, it will not receive all previously emitted data, but will only share in the data that is send after it is subscribed. This kind of source is considered to be \textit{hot}. It is strictly reactive, meaning that it can only emit data at a speed which is determined by the source and has no way to be slowed down by any \obv that cannot cope with the amount of data sent.
+Sources like clocks, stock tickers, mouse moves or key presses start emitting regardless of any \obv being subscribed to the stream. When no one is listening, the data is simply discarded; when multiple \obv instances are subscribed, every one of them receives the same data at (approximately) the same time. In case an \obv subscribes at a later time, it will not receive all previously emitted data, but will only share in the data that is send after it is subscribed. This kind of source is considered to be \textit{hot}. It is strictly reactive, meaning that it can only emit data at a speed which is determined by the source and has no way to be slowed down by any \obv that cannot cope with the amount of data sent.
 
 On the other hand there are streams that originate from sources that are actually interactive. These include the results of database queries and \ieb sequences. Often the reason for them being wrapped into an \obs is because of a potential delay that needs to be awaited before the result is returned without blocking the program flow or call stack, or simply because the context of the program requires an \obs rather than an \ieb. Regarding the former, it may (for example in case of lazy evaluation) take some time before the \ier has produced its next element. The \obs will however not start emitting its data immediately, like the hot variant, but will wait until at least one \obv is subscribed. Only then it will start producing its values. In case a second \obv subscribes, the stream will effectively duplicate itself and start all over again with emitting the first values. Unless specified by operator sequences, this means that the lazy \ier in the source will have to produce its values a second time as well. In the end, both the first and second \obv have received the same set of data, even though the second subscribed much later than the first. A stream with this kind of behavior is referred to as a \textit{cold} \obs.
 

report/5.0-solving-overproduction-using-feedback-control.tex

@@ -5,14 +5,18 @@ \chapter{Solving overproduction with feedback control}
 
 We also discussed several solutions to overproduction in the light of these three groups of sources. We learned that \textit{avoiding} by grouping or dropping data works perfectly for hot and cold asynchronous sources as a first line of defense. \textit{Callstack blocking} on the other hand is something that is automatically done to cold synchronous sources but can potentially be dangerous to hot and cold asynchronous sources as they might form a buffer of calls on the stack. The \textit{Reactive Streams} solution and RxJava's \textit{reactive pull} are to be used on cold sources alone, and cannot work with a hot source as they go against the contract of reactiveness as defined in \cite{berry1991-Reactive}.
 
-The central problem here is that we want a single reactive interface to share between all kinds of data streams. Although one might argue that you ought not to be using a reactive interface for an interactive (cold) source, we acknowledge the fact that in many circumstances it is more practical to view and treat them as `streaming' and `real-time' data rather than having them as interactive sources. In order to do so, we need a way to interact with cold sources in an overproduction-safe way. Reactive Streams and reactive pull achieve this by introducing the concept of backpressure and changing the reactive interface itself, making the consumer in charge, rather than the producer. Not only is this against the concept of reactiveness, it also gives many problems with implementing the operators defined on the reactive interface.
+The central problem here is that we want a single reactive interface to share between all kinds of data streams\footnote{Although one might argue that you ought not to be using a reactive interface for an interactive (cold) source, we acknowledge the fact that in many circumstances it is more practical to view and treat them as `streaming' and `real-time' data rather than having them as interactive sources.}. Note that this already works for hot sources; by definition they are suitable for a reactive interface. We only need a way to interact with cold sources in an overproduction-safe way.
 
-In this chapter we will propose an alternative to backpressure that makes use of the feedback systems described in \Cref{chap:intro-to-feedback-control,chap:feedback-api}. We already concluded that backpressure is not suitable for hot sources, so we will discard these from the discussion in this chapter. The solution proposed here will apply to interactive sources alone.
+Reactive Streams and RxJava's reactive pull achieve this by introducing the concept of backpressure and changing the reactive interface itself, making the consumer in charge, rather than the producer. Not only is this against the concept of reactiveness, it also gives many problems with implementing the operators defined on the reactive interface.
 
-\input{5.1-buffer-control}
+In this chapter we will propose an alternative to dealing with cold sources, that makes use of the feedback systems described in \Cref{chap:intro-to-feedback-control,chap:feedback-api}. We will show how the overproduction problem can be reduced to a control problem that can be solved using a feedback control system. Furthermore we provide a design and implementation for this feedback system and show how this can be fitted in the purely reactive interface that was described in \Cref{sec:pure-rx-interfaces}.
 
-\todo{not sure what to do for the next section in this chapter; want to discuss this with \href{https://github.com/gousiosg}{@gousiosg}}
-\section*{Next section(s)???}
-Most likely I want to show some examples of where to apply this feedback based overflow control. \href{https://github.com/GeorgiKhomeriki}{@georgikhomeriki} has a nice \href{https://gist.github.com/GeorgiKhomeriki/97cc281a086f5a12c96ad36fe95d0393}{gist} put together with the effects of backpressure on the RxJava Observable. I already experimented with this, translated it to Scala and added the solution from the previous section, as shown \href{https://github.com/Applied-Duality/Feedback-Control/blob/master/BackpressureControl/RxScala/src/main/scala/fbc/backpressure/BackpressureDemo.scala}{here}. However, I'm not sure if and how to present this.
+\input{5.1-overview}
 
-And what else should I do here? Not sure yet. I'm thinking of some form of scientific justification (after all, this is a university level master thesis), but I haven't figured out yet what to do.
+\input{5.2-universal-interactive-interface}
+
+\input{5.3-feedback-system}
+
+\input{5.4-controller}
+
+\input{5.5-backpressure-alternative}