commit adf7f62068e5560cb5ce6748582d1354f06f26a9
parent 44c8e946064a20030f12899d71de25bc6edea65e
Author: Joel-Haeberli <haebu@rubigen.ch>
Date: Sat, 11 May 2024 15:39:43 +0200
docs: fees and adding a new provider
Diffstat:
6 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/docs/content/appendix/project_managment.tex b/docs/content/appendix/project_managment.tex
@@ -0,0 +1,8 @@
+\subsection*{Gant Chart}
+\label{appendix-gant}
+
+%todo include gant chart%
+
+\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.
diff --git a/docs/content/implementation/a-providers.tex b/docs/content/implementation/a-providers.tex
@@ -12,11 +12,10 @@ The provider client interface defines three functions:
\begin{enumerate}
\item SetupClient: The setup function is called by the startup of the application and used to initialize the client. Here it makes sense to check that everything needed for the specific client is in place and that properties like access credentials are available.
- \item GetTransaction: This function is used by the attestation process to retrieve the transaction of the provider system. It takes the transaction identifier supplied with the payment notification message and loads the information about the transaction. Based on this information the decision to confirm or abort the transaction is done.
+ \item GetTransaction: This function is used by the attestation process to retrieve the transaction of the provider system. It takes the transaction identifier supplied with the withdrawal confirmation request and loads the information about the transaction. Based on this information the decision to confirm or abort the transaction is done.
\item Refund: Since the transaction of the money itself is done by the provider, also refunds will be unwind by the provider. This functions mean is to trigger this refund transaction at the provider.
\end{enumerate}
-
\subsubsection{Provider Transaction}
\label{sec-provider-transaction-interface}
@@ -25,7 +24,7 @@ Since the attestation process is implemented to support any provider, also the t
The provider client interface defines following functions:
\begin{enumerate}
- \item AllowWithdrawal: This function shall return true, when the transaction received by the provider enters a positive final state. This means that the provider accepted the transaction and could process it.
+ \item AllowWithdrawal: This function shall return true, when the transaction received by the provider enters a positive final state. This means that the provider accepted the transaction and could process it. This means that the \textit{Exchange} can create the reserve and allow the customer the withdrawal of the digital cash.
\item AbortWithdrawal: It doesn't mean that if a transaction does not allow to do the withdrawal, that the transaction shall be cancelled immediately. It could also be that the transaction was not yet processed by the provider. In this case we need means to check if the provider transaction is in an abort state if it is not ready for withdrawal, before aborting it. AbortWithdrawal shall therefore answer the question if the provider transaction is in a negative final state, which means the transaction is to be aborted.
\item Bytes: This function shall return a byte level representation of the transaction which will be used as proof of the transaction and stored in the exchanges database.
\end{enumerate}
@@ -45,4 +44,8 @@ To integrate Wallee as provider into C2EC, the provider client interface as desc
\subsubsection{Simulation Client}
-Additionally to the Wallee Client a Simulation Client was implemented which can be used for testing. It allows end-to-end tests of the C2EC component by stubbing the actions performed against a provider and returning accurate results.
-\ No newline at end of file
+Additionally to the Wallee Client a Simulation Client was implemented which can be used for testing. It allows end-to-end tests of the C2EC component by stubbing the actions performed against a provider and returning accurate results.
+
+\subsubsection{Adding a new provider}
+
+To add a new provider, the client- and transaction-interfaces must be implemented as described in \autoref{sec-provider-client-interface} and \autoref{sec-provider-transaction-interface}. The \texttt{SetupClient} function of the client interface must make sure to register itself to the global map of registered providers. Additionally, to the newly added provider implementation, the provider must also be registered in the database (\autoref{sec-implementation-cli} describes how to achieve this). When the client adds itself to the registered providers clients, the application will load the provider client at startup of C2EC. If C2EC fails to find the specified provider in the database, it won't start. This behaviour makes sure, that only needed providers are running and that if a new provider was added, it is effectively registered and configured correctly (the setup function of the provider interface is responsible to check the provider specific configuration and do readiness or liveness checks if needed). If the new added provider requires a new payto target type, a new entry is to be created with the GANA in order to prevent conflicts in the future.
+\ No newline at end of file
diff --git a/docs/content/implementation/f-cli.tex b/docs/content/implementation/f-cli.tex
@@ -13,10 +13,10 @@ Adding the Wallee provider is as easy as calling \textit{rp} (register-provider)
Adding a Wallee terminal can be achieved by using the \textit{rt} (register-terminal) command. It will ask the user to enter the description of the terminal and will then generate a 32-byte access token using Go's crypto random library which must be supplied to the owner of the terminal through a secure channel with the \textit{terminal-user-id} (which is just the name of the operator and the id of the terminal separated by a dash '-')
-\subsection(Deactivating the terminal)
+\subsection{Deactivating the terminal}
To deactivate the terminal, the command \textit{dt} must be issued. It will ask for the \textit{terminal-user-id} of the terminal and then deactivate the specified terminal. The deactivation will be immediately and therefore helps to increase the security by allowing immediate action, when a terminal is come to be knwon hijacked, stolen or other fraud is detected specific to the terminal.
-\subsection(Setting up the Simulation)
+\subsection{Setting up the Simulation}
The Simulation provider and terminal allow to simulate transactions and interactions of the terminal with the API of C2EC. Therefore the command \textit{sim} will setup the needed provider and terminal including the credentials of the simulation terminal, which must be saved to the operator in order to test API using the simulation terminal.
diff --git a/docs/content/implementation/testing.tex b/docs/content/implementation/f-testing.tex
diff --git a/docs/thesis.pdf b/docs/thesis.pdf
Binary files differ.
diff --git a/docs/thesis.tex b/docs/thesis.tex
@@ -190,6 +190,7 @@
\input{content/architecture/overview}
\chapter{Architecture}
+\label{sec-architecture}
\input{content/architecture/c2ec}
\input{content/architecture/wallet}
\input{content/architecture/wallee}
@@ -232,17 +233,17 @@
\printindex
%------------ Appendix ----------------
\appendix
-\chapter{Appendix A}
-\section{API}
+\chapter*{Appendix A}
+\section*{API}
\label{appendix-api-spec}
\lstinputlisting[style=rst,caption={C2EC API specification}]{listings/specs/api-c2ec.txt}
-\chapter{Appendix B}
-\section{Project Management}
+\chapter*{Appendix B}
+\section*{Project Management}
\input{content/appendix/project_managment}
-\chapter{Appendix C}
-\section{Meeting notes}
+\chapter*{Appendix C}
+\section*{Meeting notes}
\input{content/appendix/meeting_notes}
\end{document}
