further doc work

chapters/architecture/System-Design.typ

@@ -9,28 +9,23 @@ To achieve this, tests are written using the official Hashicorp vault go client.
 
 The Webserver forwards client requests to different routers according to the request paths:
 i.e. "/v1/auth" for the authorization router.
-Those routers map request to their corresponding handlers.
+Those routers map requests to their corresponding handlers.
 
 Problem: 
 - TODO describe middleware
 
 === Engines
 
+Engines are used to manage data. Depending on the engine this can include storage, generation and encryption. Each engine is independent from other engines.
+Different engines are addressed via a path, which is passed as a prefix to the secret path. The path for the key-value storage would be .../kv-v2/foo. 
 
+In the code, engines are represented by folders which are divided into a logic section, struct sections and a test section.
 
 === Storage
 
-Engines:
+Data is currently stored in an SQLite databse which is accessed with SQLX without ORM. Later stages of the project will allow for different storage systems to be used.
 
-Der Engines Ordner enthält Subfolder
+=== Overview
-für die jeweilige Engine unterteilt
-in Logik, Structs unt Tests
-
-
-Storage:
-
-Momentan beschränken wir uns auf SQLite
-über SQLX ohne ORM
 
 #figure(
   image("../../assets/Design.svg", width: 80%),
@@ -38,31 +33,3 @@ Momentan beschränken wir uns auf SQLite
     The acting components of rvault.
   ],
 )
-
-=== Design decisions
-
-
-
-// + The API to implement e.g. has the concept of mount points (similar to how filesystems can be mounted on UNIX-like systems).
-// 	Mount points can contain multiple slashes.
-// 	For example `/v1/some/mount/point/data/some/path/secret` may consist of a mount point `some/mount/point` and further, following routes of the mapped secret engine. //TODO
-// 	In this example, `/data` is related to the Key-Value engine and `/some/path/secret` specifies a path within the secret engine instance mounted at the mount point.
-// 	This implies a significant problem:
-// 	How to determinate what part of the URL displays a mount point, where it is not certan, what the postfix of the URL will be (this problem follows).
-
-// + Another problem is that based on the mount point, the request must be processed by the applicable secret engine.
-// 	Based on context, stored on the DBMS, the request must be passed to the secret engine along with the determinated mount point.
-
-=== Solution
-
-// Secret Engines have their dedicated router.
-// The main router has an instance of these routers along with the database pool wrapped within a struct in its state.
-// The router instances have a reference to the database pool, which is internally wrapped by an Atomic Reference Counter (`Arc`).
-
-// Upon a requst, the remaining path is obtained (via `/+mount_path`).
-// Then, the path is looked up at the database, also requsting the engine type.
-// If not found, the last last slash character and the following string is removed and looked up again. This is repeated, until the path either is found or has a length of zero, rejecting the request as "404 Not Found".
-
-// If found, the router is called with the request and mount path is given to the router as an "Extension".
-// The `call` #link("https://docs.rs/tower/0.4.13/tower/trait.Service.html#tymethod.call")[(link)]
-// function which Axum routers inherit from the Tower crate, allows to hand the request over to engine's router.

rvault_description.txt

@@ -14,3 +14,5 @@ Implemented features include:
 - Design of the architecture 
 - Implementation of dynamic routing to allow for exchangeable secret engines
 - Basic kv-store
+
+The main development branch is the engine-kv branch.