Did stuff

src/bib.bib

@@ -457,3 +457,31 @@
     pages     = {945--958},
     year      = {2007},
 }
+
+@misc{so-survey-2016,
+  title = {Developer Survey Results 2016},
+  year = {2016},
+  author = {Stack Overflow},
+  howpublished = {\url{https://insights.stackoverflow.com/survey/2016#technology-most-loved-dreaded-and-wanted}}
+}
+
+@misc{so-survey-2017,
+  title = {Developer Survey Results 2017},
+  year = {2017},
+  author = {Stack Overflow},
+  howpublished = {\url{https://insights.stackoverflow.com/survey/2017#technology-most-loved-dreaded-and-wanted}}
+}
+
+@misc{so-survey-2018,
+  title = {Developer Survey Results 2018},
+  year = {2018},
+  author = {Stack Overflow},
+  howpublished = {\url{https://insights.stackoverflow.com/survey/2018#technology-most-loved-dreaded-and-wanted}}
+}
+
+@misc{so-survey-2019,
+  title = {Developer Survey Results 2019},
+  year = {2019},
+  author = {Stack Overflow},
+  howpublished = {\url{https://insights.stackoverflow.com/survey/2019#technology-most-loved-dreaded-and-wanted}}
+}

src/config.sty

@@ -1,6 +1,6 @@
 \usepackage{natbib}
 \bibliographystyle{abbrvnat}
-\setcitestyle{authoryear,open={[},close={]}}
+\setcitestyle{authoryear,open={[},close={]},citesep={,}}
 
 \usepackage{multirow}
 \usepackage[colorlinks = true,

src/dash-3d-implementation/js-implementation.tex

@@ -1,5 +1,6 @@
 \fresh{}
-\section{Worker}
+\section{JavaScript implementation}
+
 In JavaScript, there is no way of doing parallel computing without using \emph{web workers}.
 A web worker is a script in JavaScript that runs in the background, on a separate thread and that can communicate with the main script by sending and receiving messages.
 Since our system has many tasks to do, it seems natural to use workers to manage the streaming without impacting the framerate of the renderer.

src/dash-3d-implementation/main.tex

@@ -3,8 +3,12 @@
 \input{dash-3d-implementation/introduction}
 \resetstyle{}
 
-\input{dash-3d-implementation/worker}
-\resetstyle{}
-
 \input{dash-3d-implementation/media-engine}
 \resetstyle{}
+
+\input{dash-3d-implementation/js-implementation}
+\resetstyle{}
+
+\input{dash-3d-implementation/rust-implementation}
+\resetstyle{}
+

src/dash-3d-implementation/rust-implementation.tex

@@ -0,0 +1,32 @@
+\section{Rust implementation}
+
+In order to run our simulation, we want to have a native implementation of our DASH client that is performant and reliable.
+We chose to use Rust to accomplish this.
+
+\subsection{Rust language}
+Rust is a system programming language focused on safety.
+Developpers coming from C++ (as myself) might see it as a language like C++ but that forbids undefined behaviours.\footnote{in Rust, when you need to execute code that might lead to undefined behaviours, you need to put it inside an \texttt{unsafe} block. Many operations will not be available outside an \texttt{unsafe} block (e.g., dereferencing a pointer, or mutating a static variable). The idea is that you can use \texttt{unsafe} blocks when you require it, but you should avoid it as much as possible.}
+This makes segmentation fault extremely rare, and it also makes the compiler giving comprehensible error messages instead of letting code compile that would crash on the first run.
+Other concepts (such as concepts from functional programming) make it very confortable to write Rust code.
+Furthermore, Rust comes with great tooling.
+\begin{itemize}
+    \item \href{https://github.com/rust-lang/rust}{\textbf{\texttt{rustc}}} is the Rust compiler. It is very confortable due to the nice error messages it displays.
+    \item \href{https://github.com/rust-lang/cargo}{\textbf{\texttt{cargo}}} is the official Rust's project and package manager. It manages compilation, dependencies, documentation, tests, etc\ldots
+    \item \href{https://github.com/racer-rust/racer}{\textbf{\texttt{racer}}}, \href{https://github.com/rust-lang/rls}{\textbf{\texttt{rls}} (Rust Language Server)} and \href{https://github.com/rust-analyzer/rust-analyzer}{\textbf{\texttt{rust-analyzer}}} are software that manage automatic compilation to display errors in code editors as well as providing semantic code completion.
+    \item \href{https://github.com/rust-lang/rustfmt}{\textbf{\texttt{rustfmt}}} auto formats code.
+    \item \href{https://github.com/rust-lang/rust-clippy}{\textbf{\texttt{clippy}}} is a linter that detects unidiomatic code and suggests modifications.
+\end{itemize}
+It is probably for those reasons that Rust is the \emph{most loved programming language} according to the Stack Overflow Developper Survey in~\citeyear{so-survey-2016,so-survey-2017,so-survey-2018} and~\citeyear{so-survey-2019}.
+
+\subsection{Specific requirements}
+Our requirements are quite different that the ones we had to deal with in our JavaScript implementation.
+In this setup, we want to build a system that is the closest to our theoritical concepts.
+Therefore, we do not have a full client in Rust (meaning an application to which you would give the URL to an MPD file and that would allow you to navigate in the scene while it is being downloaded).
+Doing so is feasible, of course, but not what we want.
+In order to be able to run simulations, we develop the bricks of the DASH client separately: the access client and the media engine are totally separated:
+\begin{itemize}
+    \item the \textbf{simulator} takes a user trace as a parameter, it then replays the trace using specific parameters of the access client and outputs a file containing the history of the simulation (what files have been downloaded, and when);
+    \item the \textbf{renderer} takes the user trace as well as the history generated by the simulator as parameters, and renders images that correspond to what would have been seen.
+\end{itemize}
+When simulating experiments, we will run the simulator on many traces that we collected during user-studies, and we will then run the renderer program on it to generate images corresponding to the simulation.
+We are then able to compute PSNR between those frames and the ground truth frames.