commit 6819f346a3c78f107e6fad2256295978f7b39276
parent a08d6a592bd026273ce435590c2f94ce6b242792
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Mon, 27 May 2024 20:51:25 +0200
docs: save commit
Diffstat:
8 files changed, 80 insertions(+), 18 deletions(-)
diff --git a/docs/content/acknowledgements.tex b/docs/content/acknowledgements.tex
@@ -0,0 +1,9 @@
+I would like to thank Prof. Dr. Benjamin Fehrensen and Prof. Dr. Christian Grothoff for their support during the thesis. Their knowledge and feedbacks helped me to work towards the thesis objectives and the reflection of my work. They pushed me to implement the product and motivated me to work hard.
+
+The GNU Taler team deserves a big thank you to discuss, reflect and sharpen the Terminals API which was an important part of the thesis.
+
+Also I thank my colleagues from the class who motivated me during thesis. Especially I would like to thank Jan Fuhrer for the nice friday night coding sessions, Christian Blättler for the valuable discussion about Taler and Andy Bigler for the exchange about Android applications. They were crucial to gain a better understanding of how the components work and how I must do the implementation.
+
+Additionally I would like to thank Meret Staub for her critical eyes and thoughts during the proofreading of the thesis.
+
+Last but not least I thank Flurina from all my heart. You were not mad at me when I had to cancel dinner, because I wanted to write some code.
diff --git a/docs/content/appendix/project_managment.tex b/docs/content/appendix/project_managment.tex
@@ -1,8 +1,45 @@
-\subsection*{Gant Chart}
\label{appendix-gant}
-
-%todo include gant chart%
+\begin{figure}[H]
+ \centering
+ \begin{ganttchart}[
+ hgrid,
+ vgrid,
+ x unit=0.1cm,
+ y unit title=0.7cm,
+ y unit chart=0.7cm,
+ time slot format=isodate,
+ title/.append style={draw=none, fill=orange!50}
+ ]{2024-02-19}{2024-06-14}
+ \gantttitlecalendar{year, month=shortname} \\
+
+ \ganttgroup{Concept}{2024-02-19}{2024-03-20} \\
+ \ganttbar{Get to know Wallee}{2024-02-19}{2024-03-06} \\
+ \ganttbar{Get to know GNU Taler}{2024-02-19}{2024-03-06} \\
+ \ganttbar{Identify areas of work}{2024-02-19}{2024-03-06} \\
+ \ganttbar{API Specification}{2024-03-06}{2024-03-20} \\
+ \ganttbar{UX Specification}{2024-03-06}{2024-03-20} \\
+
+ \ganttgroup{Implementation}{2024-03-20}{2024-05-22} \\
+ \ganttbar{C2EC}{2024-03-20}{2024-04-27} \\
+ \ganttbar{Wallee Terminal}{2024-04-27}{2024-05-15} \\
+ \ganttbar{Installation}{2024-04-27}{2024-05-15} \\
+ \ganttbar{Testing}{2024-05-01}{2024-05-22} \\
+
+ \ganttgroup{Documentation}{2024-02-19}{2024-06-14} \\
+ \ganttbar{Goal}{2024-02-19}{2024-03-06} \\
+ \ganttbar{Architecture}{2024-03-06}{2024-03-27} \\
+ \ganttbar{Implementation}{2024-03-27}{2024-05-22} \\
+ \ganttbar{Proofreading}{2024-05-22}{2024-06-07} \\
+ \ganttbar{Print Thesis}{2024-06-08}{2024-06-13} \\
+ \ganttbar{Book Entry}{2024-05-08}{2024-05-26} \\
+ \ganttbar{Poster}{2024-05-08}{2024-05-26} \\
+ \ganttbar{Video}{2024-05-27}{2024-06-13} \\
+ \ganttbar{Presentation}{2024-05-27}{2024-06-14} \\
+ \end{ganttchart}
+ \caption{The project plan}
+ \label{fig-appendix-gant}
+\end{figure}
\subsection*{Iterative approach}
-During the project, each week a plan is made which described the tasks for the week. The plan is made on paper and hanged above my desk so I can see it. I inform the thesis advisors during the weekly synch call and change them if needed. For the prioritisation of work, the project plan in \autoref{appendix-gant} was used. This iterative approach helps to adapt to changing requirements and environment fast. Since I am working alone on the project, there is no need for more methodological overhead or to implement some alibi project organisation. Requirements are captured as specifications within the Taler documentation repository or in the architecture section (\autoref{sec-architecture}). As part of the weekly planning I reflect the past work and therefore can change what I think is necessary. Questions and impediments are directly addressed through the channel and/or person I think can help me with it.
+During the project, each week a plan is made which described the tasks for the week. The plan is made on paper and hanged above my desk so I can see it. I inform the thesis advisors during the weekly synch call and change them if needed. For the prioritisation of work, the project plan in \autoref{appendix-gant} was used. This iterative approach helps to adapt to changing requirements and environment fast. Since I am working alone on the project, there is no need for more methodological overhead or to implement a big project organisation. Requirements are captured as specifications within the Taler documentation repository or in the architecture section (\autoref{sec-architecture}). As part of the weekly planning I reflect the past work and therefore can change what I think is necessary. Questions and impediments are directly addressed through the channel and/or person I think can help me with it.
diff --git a/docs/content/glossary.tex b/docs/content/glossary.tex
@@ -1,5 +0,0 @@
-\newglossaryentry{TEST}{
- name={TEST},
- description={TEST},
- plural=TESTS
-}
diff --git a/docs/content/methods.tex b/docs/content/methods.tex
@@ -1,2 +0,0 @@
-\section{Methods}
-What did you do? – a section which details how the research was performed. It typically features a description of the participants/subjects that were involved, the study design, the materials that were used, and the study procedure. If there were multiple experiments, then each experiment may require a separate Methods section. A rule of thumb is that the Methods section should be sufficiently detailed for another researcher to duplicate your research.
diff --git a/docs/content/results/discussion.tex b/docs/content/results/discussion.tex
@@ -1,31 +1,33 @@
\section{Discussion}
-What is the significance of your results? – the final major section of text in the paper. The Discussion commonly features a summary of the results that were obtained in the study, describes how those results address the topic under investigation and/or the issues that the research was designed to address, and may expand upon the implications of those findings. Limitations and directions for future research are also commonly addressed.
Our work shows that withdrawals in GNU Taler are possible using the payment service provider Wallee. The C2EC implementation shows how the process can be implemented and integrated into the rest of the Taler ecosystem.
The design of the Terminals API was a major field of work during the process. Only after a few iterations, the specification was ready. The iterations were necessary to sharpen the understanding of how the terminal and C2EC must interact and integrate with the existing Taler components in order to make the withdrawals functional.
-The implementation of the existing Bank-Integration and Wire-Gateway API were a challenge because they must be implemented with great care to not violate the specification. Another challenging task was the design of C2EC. To create a useful, robust and extensible design, other components of Taler must have been understood. This task was a little more time consuming than initially planned.
+The implementation of the existing Bank-Integration and Wire-Gateway API were a challenge because they must be implemented with great care to not violate the specification. Another challenging task was the design of C2EC. To create a useful, robust and extensible design other components of Taler must have been understood. This task was a little more time consuming than initially planned. I thought at first that I would understand how to implement C2EC and then just simply do it. In reality the process was iterative. Only after a lot of iterations I was able to find a suitable way for the implementation.
A challenge which was encountered during the implementation of the terminal application and the C2EC component, was the concurrency of processes. To make the withdrawal flow as easy and useful as possible to the user, a lot of tasks need to be covered in the background and run in parallel. This added the technical requirement to decouple steps and leverage retries to increase the robustness of the process.
-During the integration phase towards the end of the implementation it became obvious that a simple authorization was not enough to imitate the real time feeling of the withdrawal. Other Requests were necessary to do so. To findout which requests needed to be filed against the Wallee backend needed to be investigated. The documentation does explain which states exists in Wallee's transaction scheme but it does not explain, which operation do trigger the transition of one state to another.
+Towards the end of the implementation it became obvious that a simple authorization was not enough to imitate the real time feeling of the withdrawal. Other Requests were necessary to do so. To findout which requests needed to be filed against the Wallee backend some investigation had to be made. The documentation does explain which states exists in Wallee's transaction scheme but it does not explain, which operation do trigger the transition of one state to another. This made the investigation somewhat cumbersome. Also the integration of the backend needed more investigation than I thought.
\section{Future Work}
-As stated in the discussion the implementation of the framework does suffer from some architectural short comings. Also other parts must be further improved. Additionally to such clean up duties, the system can be extended. To give myself and others interested to collaborate some ideas what can be done, I provide a list of future work. The list might not be complete and any new idea is appreciated. I split the future work into two parts. The second list, is a list of ideas how the existing logic can be extended to make the system easier to use or to add new functionality. The second list contains technical debts.
+C2EC introduces new ways to access digital cash using GNU Taler. Due to the short time available during the thesis, features and integrations are missing which can make it even more valuable. Because of this I provide a list of future work. Maybe there are other students or collaborators who want to join in and add their features to the existing code. The list might not be complete and any new ideas are appreciated. I splitted the list into the list of extensions and improvements.
\subsection{Extensions}
\begin{enumerate}
\item Integration of other providers: To make use of the implemented structures, it would be nice to add more payment service providers.
\item Management interface for terminals: To allow easier use of the system it might be nice to have a more sophisticated interface to manage terminals. The implemented CLI helps to get an understanding, how such a management interface could add terminals to the system.
- \item Automated registration: With increasing use, it might be nice for the operator to allow an automatic registration of new terminals.
+ \item Automated registration: With increasing use of C2EC, it might be nice for the operator to allow an automatic registration of new terminals.
\item Support quotas: To fully support the Terminals API, the quotas endpoints could be implemented.
\item Proper packing: To fully integrate into the Taler landscape, C2EC should be packed and installed like other Taler components such as the Exchange.
\end{enumerate}
-\subsection{Technical debt}
+\subsection{Improvements}
\begin{enumerate}
+ \item Run the existing implementation as part of the BFH Taler CHF-Exchange
+ \item Approve Paydroid app: Let Wallee check the terminal app and run it on a Wallee terminal on behalf of the BFH.
\item C2EC: Remove doubled provider structures. Currently providers are saved to the database and must be configured in the configuration. To make the setup and management easier, the providers could only be configured inside the configuration.
\item App: Automatically trigger long poll request for parameter selection. Due to the lack of time, the long-poll request for the parameter selection on the side of the terminal was not implemented to be automatically but will only be sent, when the user clicks on the \textit{authorize} button. The request shall be triggered in the background instead.
+ \item The Wallee-Transaction payto target type is currently abused and not implemented in conformance of the specification in the GANA. To resolve this issue, the Wallee-Transaction identifier needs to be saved alongside the merchant reference which is currently used for the lookup of the transaction.
\end{enumerate}
diff --git a/docs/content/results/reflexion.tex b/docs/content/results/reflexion.tex
@@ -2,6 +2,22 @@
\subsection{Technically}
+Generally I think I did an acceptable job in the implementation. I was able to implement the required processes and the targeted user-experience. The implementation (in C2EC as well as in the Paydroid app) suffers of some technical debts which I finally accepted, because I had to prioritize the formal parts of the thesis, such as the poster, video, book entry or this documentation. I could have prevented some of these issues, when I read the documentation and specification more concentrated.
+
+\subsubsection{C2EC}
+
+The implementation of C2EC was the biggest part of my work during the thesis. It is the core of the framework and I had to think about API specification conformance, extensibility, correctness and database integration. I wanted to achieve an architecture, which is similar to the one of the GNU Taler Exchange. This inlcuded to decouple steps in the withdrawal process using triggers and the notify feature of postgres. I learned a lot about how postgres works and how I can write working postgres functions and triggers. First I failed to properly document the database fields, tables and functions. After a review with Prof. Dr. Christian Grothoff I learned about the comment functionality of the postgres SQL standard.
+
+In Go code of the C2EC component I had to implement a robust way to communicate between parallel running processes. Go's concurrency model made this possible in an easy and what I think, comprehensible way. I correctly anticipated that it would pay out to first implement the concepts for my requirements in a dummy project and then adapt this to C2EC. Additionally the implementation of the database access layer behind an interface allows to change the database easily.
+
+Concerning the extensibility of C2EC I was able to implement nice code level abstractions which allow an easy integration of additional payment system providers. After the feedback of Prof. Dr. Christian Grothoff I was able to eliminate an unnecessary layer of abstraction, which makes it even easier.
+
+\subsubsection{Paydroid Terminal Application}
+
+The paydroid application was challenging to me since I never wrote a real Android application on my own. Therefore I think I did a good job by implementing a best practice structure with the view models, composable and navigation controller. Through the feedback of Prof. Dr. Benjamin Fehrensen I was able to verify the correctness of these best practices. I first had problems to understand how exactly the versioning in Android works and that the backward compatibility is given even in big time gaps. In the beginning I suffered a little to understand the difference of the none compose and compose era of Android programming. Since the app needs to do stuff in the background I had to understand how this could be achieved. Therefore I needed to understand how I can access other threads. I think in this area is the biggest shortcoming of my implementation. I failed to implement a proper asynchronous state-handling. Threads running detached from the UI-Thread will update the model, which will lead to the regeneration of the composables. I think it would be a better way to implement a proper pub / sub model using a library like rxjs or similar. Due to the lack of time I decided to not do this anymore.
+
\subsection{Methodically}
+
+
\subsection{Personally}
\ No newline at end of file
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
Binary files differ.
diff --git a/docs/thesis.tex b/docs/thesis.tex
@@ -55,6 +55,9 @@
\usepackage{pdfpages}
+\usepackage{pgfgantt}
+\usetikzlibrary{arrows.meta,fit,positioning,shapes.geometric}
+
%---------------------------------------------------------------------------
% Graphics paths
%---------------------------------------------------------------------------
@@ -74,7 +77,6 @@
%---------------------------------------------------------------------------
\usepackage[nonumberlist]{glossaries-extra}
\makeglossaries
-\input{content/glossary}
%---------------------------------------------------------------------------
% Makeindex Package
%---------------------------------------------------------------------------
@@ -178,6 +180,9 @@
%---------------- BFH tile page -----------------------------------------
\maketitle
+%------------ ACKNOWLEDGMENT ----------------
+\addchap{Acknowledgements}
+\input{content/acknowledgements}
%------------ ABSTRACT ----------------
\addchap{Abstract}
\input{content/abstract}
