commit d3e3d4560b708f5254ecced25f8a62bdd5068cf9
parent 56180148c5f641cfca0b7004a7ff2756231a4a7f
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Sat, 8 Jun 2024 09:38:39 +0200
docs: enhance
Diffstat:
5 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/docs/content/acknowledgements.tex b/docs/content/acknowledgements.tex
@@ -2,7 +2,7 @@ I would like to thank Prof. Dr. Benjamin Fehrensen and Prof. Dr. Christian Groth
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 the thesis. Especially I would like to thank Jan Fuhrer for the nice friday night coding sessions, Christian Blättler for the valuable discussion about GNU 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.
+Also I thank my colleagues from the class who motivated me during the thesis. Especially I would like to thank Jan Fuhrer for the nice Friday night coding sessions, Christian Blättler for the valuable discussion about GNU 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 thoughts during the proofreading of the thesis.
diff --git a/docs/content/implementation/e-cli.tex b/docs/content/implementation/e-cli.tex
@@ -1,7 +1,7 @@
\section{C2EC CLI}
\label{sec-implementation-cli}
-The management of providers and terminals is not part of the thesis but since writing and issueing SQL statements is cumbersome and error-prone a small cli was implemented to abstract managment tasks. The cli tool was also shows the concepts a future implementation of the provider managment can use to integrate with the present features. The cli can be extended with more actions to allow the management of other providers and its terminals. Also the cli allows to setup the simulation terminal and provider which can be used for testing. Before commands can be executed, the user must connect the tool to the database which can be done throught the \textit{db} command. With the aim to not introduce security risks by storing configuration state of the cli, the credentials must be entered after each startup of the cli. This can be surpassed by specifying postgres specific environment variables \texttt{PGHOST}, \texttt{PGPORT}, \texttt{PGUSER} and \texttt{PGPASSWORD} but remember that these environment variables might leak database credentials to others if not cleaned properly or set for the wrong users shell.
+The management of providers and terminals is not part of the thesis but since writing and issueing SQL statements is cumbersome and error-prone a small cli was implemented to abstract managment tasks. The cli tool was also shows the concepts a future implementation of the provider managment can use to integrate with the present features. The cli can be extended with more actions to allow the management of other providers and its terminals. Also the cli allows to setup the simulation terminal and provider which can be used for testing. Before commands can be executed, the user must connect the tool to the database which can be done throught the \textit{db} command or by starting the cli with the \textit{-c} option with the path to the \textit{.ini} config file containing the connection string. With the aim to not introduce security risks by storing configuration state of the cli, the credentials must be entered after each startup of the cli. This can be surpassed by specifying postgres specific environment variables \texttt{PGHOST}, \texttt{PGPORT}, \texttt{PGUSER} and \texttt{PGPASSWORD} but remember that these environment variables might leak database credentials to others if not cleaned properly or set for the wrong users shell.
The cli was implemented to be usable and as it was out of scope of the thesis, the focus was on the functionality and tasks needed for the thesis and to allow a simple management of the terminals. This included features to manage wallee provider and terminals and the simulation. Additionally the tool implements commands to activate and deactivate a terminal, which makes the task much easier than writing and executing SQL by hand.
diff --git a/docs/content/results/discussion.tex b/docs/content/results/discussion.tex
@@ -1,10 +1,10 @@
\section{Discussion}
-Our work shows that withdrawals in GNU Taler are possible using the payment service provider Wallee. The implementation shows how the objectives of finality, user-experience and security can be achieved. The C2EC implementation also shows how the process can be implemented and integrated into the rest of the Taler ecosystem.
+This thesis shows that withdrawals in GNU Taler are possible using the payment service provider Wallee. The implementation displays how the objectives of finality, user-experience and security can be achieved. The C2EC implementation also achieves the integration into the rest of the Taler ecosystem and gives a reference on how this can be achieved.
-The design of the Terminals API was a major field of work during the process. Only after several 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. At first the existing Bank-Integration API was copied and extended before merging the copy with the existing Bank-Integration API. After this step we extracted terminal specific endpoints to the new Terminals API. Like this the separation of terminal and wallet specific functionality could have been achieved. We were able to keep changes to the existing Bank-Integration API low and therefore allow the integration of the wallet without further changes.
+The design of the Terminals API was a major field of work during the process. Only after several 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. At first the existing Bank-Integration API was copied and extended before merging the copy with the existing Bank-Integration API. After this step I extracted terminal specific endpoints to the new Terminals API. Like this the separation of terminal and wallet specific functionality could have been achieved. The current implementation keeps changes to the existing Bank-Integration API low and therefore allow the integration of the wallet without further changes.
-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. Making C2EC a useful, robust and extensible, required the understaning of details of Taler such as byte encodings or amount handling. This task was a little more time consuming than initially planned. At first It was assumed that C2EC would just be implemented and work. This was a bit optimistic. In reality the process was iterative. Only after a lot of iterations a suitable way for the implementation was found.
+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. Making C2EC a useful, robust and extensible, required the understaning of details of Taler such as byte encodings or amount handling. This task was a little more time consuming than initially planned. At first, I assumed that C2EC would just be implemented and work. This was a bit optimistic. In reality the process was iterative. Only after a lot of iterations a suitable way for the implementation was found.
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, a lot of tasks need to be covered in the background and run besides each other. This added the technical requirement to decouple steps and leverage retries to increase the robustness of the process. It helped a lot to understand that the state of a withdrawal was the anchor these retry mechanisms must be built around.
@@ -26,12 +26,13 @@ Due to the short time available during the thesis, features and integrations are
\end{enumerate}
\subsection{Improvements}
+\label{sec-results-improvements}
\begin{enumerate}
\item Paydroid app: Run a Wallee terminal on behalf of the BFH.
\item Paydroid app: The app must be released including the credentials. This is a security risk since these credentials are shipped through (secure?) channels. A way to register to an exchange in the app is a nice extension.
\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 can only be configured inside the configuration.
\item C2EC: Proper separation of confirmed and unconfirmed withdrawals to reduce complexity of the implementation.
- \item C2EC: Only one provider per instance is allowed to use the same a payto target-type. Currently an additional instance must be configured, if two or more payment service providers are using the same payto target type.
+ \item C2EC: Only one provider per instance is allowed to use the same payto target-type. Currently an additional instance must be configured, if two or more payment service providers are using the same payto target type.
\item Implement more fee models: To allow easier integration of other providers, the described fee models can be centralized in one location. This would help to improve the quality and robustness of the system.
\item Database locking: Currently no database locking is used. This can lead to race conditions. To completely prevent this locks can be applied.
\item IPv6 support: The process must also listen on IPv6 addresses.
diff --git a/docs/content/results/reflexion.tex b/docs/content/results/reflexion.tex
@@ -2,31 +2,31 @@
\subsection{Technically}
-Generally I think the implementation does its job very good. 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. But overall I am satisfied with the work I did concerning the small time range that was available for the implementation.
+Generally, I think the implementation does its job very well. 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 (listed in \autoref{sec-results-improvements}). I finally accepted them, 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, if I would have read the documentation and specification more carefully. But overall I am satisfied with the work I did concerning the short time span that was available for the implementation.
\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.
+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. The Go concurrency model made this possible in an straight forward 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 without changing the entire application.
+In Go code of the C2EC component I had to implement a robust way to communicate between parallel running processes. The Go concurrency model made this possible in an straight forward 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 them to C2EC. Additionally, the implementation of the database access layer behind an interface allows to change the database without changing the entire application.
-Concerning the extensibility of C2EC I was able to implement code level abstractions which allow an seemless integration of additional payment system providers. After the feedback of Prof. Dr. Christian Grothoff I was could eliminate an unnecessary layer of abstraction, which made it even easier.
+Concerning the extensibility of C2EC I was able to implement code level abstractions which allow an seemless 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 made it even easier.
-I think I could apply a lot of knowledge I gained through the past three years. From time to time I was thinking: "ah, this is why the Prof. told us this". This helped me to harden my understanding of topics such as encoding, REST API, concurrency and many more.
+I think I have been able to apply a lot of the knowledge I have gained over the last three years. From time to time I thought: "ah, this is why the professor told us this". This helped me to deepen my understanding of topics like encoding, REST API, concurrency and many more.
\subsubsection{Paydroid Terminal Application}
-The paydroid application was challenging to me since I never wrote a real Android application on my own. That is why 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 improve the design and verify the correctness of these best practices.
+The paydroid application was challenging to me since I never wrote a real Android application on my own. That is why I think I did a good job by implementing a best practice structure with the view models, composable and navigation controller. Thanks to the feedback of Prof. Dr. Benjamin Fehrensen, I was able to improve the design and verify the correctness of these best practices.
I first had problems to understand how exactly the versioning in Android works. The backward compatibility is given even when big time gaps between the feature needed and the version in use occur. In the beginning I suffered to understand the difference of the none compose and compose era of Android programming and mixed the patterns. After better understanding how features work in jetpack compose I think I implemented a modern Android app.
-Since the app needs to do requests 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 implemented an 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 libraries like rxjs or Androids state flow features. Due to the lack of time I decided to not do this anymore.
+Since the app needs to do requests 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 implemented an 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 the asynchronous tasks using Androids state flow features. Due to the lack of time I decided to not do this anymore.
It was interesting to learn about the difference of Go goroutines and Kotlin coroutines. While running background tasks using goroutines works perfectly fine, in Kotlin on Android I learnt it is required to start a new thread and launch coroutines on the new thread. Otherwise Android will not allow network requests, because it disallows I/O operations on its UI thread. From my point of view this shows a limitation of coroutines on top of JVM threads. They are not real parallel but just suspend work on the thread and check periodically if they can process further. If there are thread level restrictions (like the Android restrictions), they will affect the execution of the coroutines on top and like this undermine the concept of coroutines.
\subsection{Methodically}
-To organize the work I did a rough planning of the work and the artefacts in the beginning. On top of this plan I did a weekly iterative planning of the work I wanted to do. This plan was presented through the weekly meeting with Prof. Dr. Christian Grothoff and Prof. Dr. Benjamin Fehrensen. Sometimes the plan needed to be sligthly adjusted due to their feedback. This led to the organization of doing my planning at thursday night so I could plan my work and adjust the plan after our weekly meeting at wednesday morning. I think I could have made the process a bit more transparent but in the end I was able to deliver the artefacts and deliverables on time. Sometimes I lost focus because there were so much loose ends to keep up with. I then did something different and ordered my thoughts. This helped sometimes but not always. When the stress level was rising this was even more difficult. In such situations taking a step back and prioritzing the work helped me.
+To organize the work I did a rough planning of the work and the artefacts in the beginning. On top of this plan I did a weekly iterative planning of the work I wanted to do. This plan was presented through the weekly meeting with Prof. Dr. Christian Grothoff and Prof. Dr. Benjamin Fehrensen. Sometimes the plan needed to be sligthly adjusted due to their feedback. This led to the organization of doing my planning at Thursday night so I could plan my work and adjust the plan after our weekly meeting at Wednesday morning. I think I could have made the process a bit more transparent but in the end I was able to deliver the artefacts and deliverables on time. Sometimes I lost focus because there were so much loose ends to keep up with. I then did something different and ordered my thoughts. This helped sometimes but not always. When the stress level was rising this was even more difficult. In such situations taking a step back and prioritzing the work helped me.
\subsection{Personally}
@@ -34,4 +34,4 @@ The world of payment systems seems a bit chaotic to me. I think this is the resu
The thesis was constrained with a lot of insecurities for me. How does the process look? How can I implement the process? How does GNU Taler even work? How does Wallee work? In the end I am proud of what I accomplished during the thesis. I was able to understand the different API and write a program which fulfills the properties needed for the withdrawal. Additionally I could learn a lot about designing an API and especially parallelization in Go and Android.
-I am thankful that the Bern University of Applied Sciences supports free software projects like GNU Taler. It was a great opportunity for me as student and as human to gain direct insights and work on a GNU project during my thesis. I remember Prof. Dr. Christian Grothoff telling me during an onsite session: "Nicht so kurzfristig denken!" (don\'t think short-term). This also showed the horizon of the project to me. It tries to sustainably change the payment landscape for good. That is what I like the most about free software. It is built to last. The world will not get better when we keep pushing towards short-term profit benefiting individuals, global warming and war. GNU Taler and other GNU projects are making a difference and take a humanitarian perspective on technology. Providing technology supporting \textit{humans}. This was the reason I started my journey in computer science with my apprenticeship in 2015 and eventually decided to do my thesis on GNU Taler. It has not changed since. Even when my contribution is small I believe it is important. When everyone adds their ideas and work to the plate, we can achieve a better world. The title picture, generously provided by cartoonist Bruno Fauser \cite{fauser}, visualizes this attitude. Sometimes it is hard to not loose faith for the good but; The good wins. Always.
+I am thankful that the Bern University of Applied Sciences supports free software projects like GNU Taler. It was a great opportunity for me as student and as human to gain direct insights and work on a GNU project during my thesis. I remember Prof. Dr. Christian Grothoff telling me during an onsite session: "Nicht so kurzfristig denken!" (don't think short-term). This also showed the horizon of the project to me. It tries to sustainably change the payment landscape for good. That is what I like the most about free software. It is built to last. The world will not get better when we keep pushing towards short-term profit benefiting individuals, global warming and war. GNU Taler and other GNU projects are making a difference and take a humanitarian perspective on technology. Providing technology supporting \textit{humans}. This was the reason I started my journey in computer science with my apprenticeship in 2015 and eventually decided to do my thesis on GNU Taler. It has not changed since. Even when my contribution is small I believe it is important. When everyone adds their ideas and work to the plate, we can achieve a better world. The title picture, generously provided by cartoonist Bruno Fauser \cite{fauser}, visualizes this attitude. Sometimes it is hard to not loose faith for the good, but do not. The good wins. Always.
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
Binary files differ.
