wrote stuff on object mapping

chapters/technische-umsetzung/main.tex

@@ -110,8 +110,44 @@ und auf welche nicht, übernimmt \textit{sync-dev-vault.py}. Die Funktionen der
     \label{fig:programmstruktur-secret-synchronizer}
 \end{nicepic}
 
+Die Funktionsweise des Programmes ist wie folgt:
+\begin{enumerate}
+    \item{Wende die Schritte $2..n$ auf alle zu synchronisierenden Entwickler*innen $d \in D$ an.}
+    \item{Lösche alle Einträge in $e_d \in d$.}
+    \item{Kopiere alle vorgesehenen Einträge $e_m \in \text{Master-Vault}$ nach $d$ und ergänze das Feld \enquote{Originale Eintrags-ID} mit dem \ac{UUID} von $e_m$.}
+    \item{Erstelle ein ID-Mapping-Objekt von $e_d$ zu $e_m$ in $d$.}
+\end{enumerate}
+
+
+\subsubsection{Performanzprobleme und Optimierung}
+Eine Schwierigkeit, die sich im Rahmen der Umsetzung offenbart hat, ist, dass das \ac{1P}-CLI sehr langsam ist.
+Soll die Liste aller Einträge eines Vaults ausgelesen werden, dauert das nach Erfahrungen des Autors etwa eine Sekunde, da es sich hierbei um \emph{eine} Anfrage handelt.
+Diese Listenansicht zeigt jedoch nur begränzte Informationen der Einträge.
+Möchte man ein bestimmtes Feld eines Eintrages \(z.B. \enquote{Originale Eintrags-ID}\) in Erfahrug bringen, müssen alle Informationen eines Eintrages
+abgefragt werden. Hier ist ein CLI-API-Aufruf pro Eintrag erforderlich. Sind einem*r Entwickler*in z.B. 30 Einträge zugeordnet, so dauert das Finden eines Eintrags
+mit einer bestimmten originalen ID im Durchschnitt $n=30; \frac{n}{2} = 15$ Sekunden. Im langsamsten Fall wären es $n=30$ Sekunden.
+Ein Kopierforgang stellt zwei Aufrufe dar (=\textit{lesen,erstellen}), also dauert das Kopieren von 30 Einträgen $n=30; 2n = 60$ Sekunden.
+Das \ac{1P}-CLI kann zwar für Detail-Aufrufe mehrere Eintrags-IDs auf Standard-Input annehmen und bearbeiten, jedoch zeigen Versuche des Autors dies zu implementieren, dass das nicht die 
+Zeitkomplexität von $O(n)$ verändert. Das heisst, eine Anfrage für 10 Einträge zu stellen, dauert in etwa zehn mal so lange,
+wie zehn Anfragen für jeweils einen Eintrag zu stellen.
+
+Eine spätere Ergänzung, um die programmatische Auslesung der Einträge in $O(n)$ anstatt $O(n^2)$ zu gewährleisten, ist die Unterhaltung von Mapping-Objekten in Entwickler*innen-Vaults.
+Je Entwickler*innen-Vault wird abschließend der Synchronisierung ein Mapping-Objekt erstellt.
+Diese Mapping-Objekte halten die Informationen vorrätig, welche öffentliche \ac{1P}-\ac{UUID} zu welcher privaten \ac{1P}-\ac{UUID} gehört.
+Ohne diese Mapping-Objekte müssten für jeden Eintrag in Entwickler*innen-Vaults der nach einer öffentlichen \ac{UUID} identifiziert wird (=Fremdschlüssel \enquote{Originale Eintrags-ID}), alle Einträge im Entwickler*innen-Vault
+abgefragt werden, bis ein Eintrag mit \enquote{Originaler Eintrag-ID = <x>} gefunden wird.
+Mit diesen Mapping-Objekten kann ein beliebiger Eintrag anhand einer öffentlichen ID
+binnen zwei Anfragen erfasst werden: Anfragen des Mapping-Objektes und Anfragen des privaten Objektes.
+Das entspricht einer Zeitkomplexität von $O(2n) = O(n)$.
+
+Desweiteren kann \ac{1P} Eintragsdaten lokal zwischenspeichern.
+Diese Option lässt sich mit dem Flag \textit{--cache} auf Leseoperationen verwenden
+und beschleunigt das Auslesen der angefragten Informationen, soweit diese im Cache existieren.
+Auf Unix-ähnlichen Betriebssystemen ist dieses Verhalten
+standardmäßig aktiviert. \cite{bib:1password-cli-caching}
+
 \subsubsection{Sicherheitsbedenken}
-Die Konfigurationsdatei definiert Zielvaults, nach ihren kryptsichen IDs. Anhand dieser IDs sieht ein*e Administrator*in keine Vaultnamen.
+Die Konfigurationsdatei definiert Zielvaults, nach ihren \acp{UUID}. Anhand dieser IDs sieht ein*e Administrator*in keine Vaultnamen.
 Wenn nun aus etwaigen Gründen dort die ID eines Nutzvaults des Partnerunternehmems aufgeführt wäre, würde das
 Werkzeug alle sich dort befindlichen Zugänge löschen. Das wäre ein Super-GAU in Form von Datenverlust.
 

dexes/acrodex.tex

@@ -15,7 +15,8 @@
     \acro{GUI}[GUI]{Graphical User Interface}
     \acro{MASA}[MASA]{Medienagenten Secret Authority}
     \acro{YAML}[YAML]{Yet Another Markup Language}
-    %\acroplural{CMS}[CMSe]{Content Management Systeme}
+    \acro{UUID}[UUID]{Universally Unique Identifier}
+    \acroplural{UUID}[UUIDs]{Universally Unique Identifiers}
 %
 %
 \end{acronym}

dexes/glossarydex.tex

@@ -15,5 +15,17 @@
         Eine arrivierte Container-Engine für Anwendungsentwicklung.
     \item [Toolbox] \hfill \\
         Eine Ansammlung an Werkzeugen, wie zum Beispiel Skripte.
+    \item [Öffentliche 1P-UUID] \hfill \\
+        Die 1P-UUID, die zu einem originalen Eintrag gehört, und nicht zu einer Referenz.
+        Externe Entwickler*innen haben also keinen direkten Zugriff auf einen solchen Eintrag, sondern müssen stattdessen eine Referenz auf diesen Eintrag verwenden.
+        Eine solche UUID kann beispielsweise in Ansible-Konfigurationdateien stehen
+        und von jedem*r Entwickler*in verwendet werden.
+    \item [Private 1P-UUID] \hfill \\
+        Die 1P-UUID, die zu einem Referenz-Eintrag gehört, und nicht zu einem originalen Eintrag. Diese Einträge sind emphemerisch und existieren ausschließlich
+        in den einzelnen Developer-Vaults und sind Entwickler*innen-spezifisch.
+    \item [Listenansicht / Listenaufruf] \hfill \\
+        Eine Anfrage, die eine Liste von Objekten oder Einträgen zurückgibt.
+    \item [Detailansicht / Detailaufruf] \hfill \\
+        Eine Anfrage, \emph{ein} Objekt oder \emph{einen} Eintrag zurückgibt oder manipuliert.
 \end{description}
 

dexes/literature.bib

@@ -2,29 +2,6 @@
 # Note that authors are "and"-seperated. The comma is part of the name. Like in "Etienne, Leon".
 # So if you have multiple authors, use "Peter and Werner and Mario and Johann"...
 
-@article{bib:leossfc,
-    author = {Maral, Gérard and de Ridder, Jean-Jacques and Evans, Barry G. and Richharia, Madhavendra},
-    title = {Low earth orbit satellite systems for communications},
-    journal = {International Journal of Satellite Communications},
-    volume = {9},
-    number = {4},
-    pages = {209-225},
-    publisher = {Wiley Online Library},
-    doi = {https://doi.org/10.1002/sat.4600090403},
-    url = {https://onlinelibrary.wiley.com/doi/abs/10.1002/sat.4600090403},
-    eprint = {https://onlinelibrary.wiley.com/doi/pdf/10.1002/sat.4600090403},
-    abstract = {Abstract It may be that we are now entering the era of LEO constellation satellite communications after thirty years of domination by the GEO systems. This paper heralds the coming of the new era with a tutorial approach to the system design and trade-offs of LEO constellation system design. It discusses orbital configurations, network topologies and routeing considerations, multiple access schemes and link performance design. In so doing it brings out the major design parameters and how they interact with each other. Also considered are the service applications for the LEO constellation systems, and the important difference between real-time and delayed communication systems is highlighted. Examples of single and multi-beam (cellular) coverage system link designs are presented for L-Ka frequency bands. Future papers will consider aspects of the LEO spacecraft and launchers.},
-    year = {1991}
-}
-
-# Example Website
-@misc{bib:typo3-frontpage,
-  author       = {{TYPO3 Association}},
-  howpublished = "\url{https://typo3.org/}",
-  title        = {{ TYPO3 — the Professional, Flexible Content Management System }},
-  year         = {2024},
-  note         = {Zugriff: Mai 2024}
-}
 
 @misc{bib:ansible,
   author       = {{Red Hat, Inc.}},
@@ -41,3 +18,11 @@
   year         = {2019},
   note         = {Zugriff: Januar 2025}
 }
+
+@misc{bib:1password-cli-caching,
+  author       = {{1Password}},
+  howpublished = "\url{https://developer.1password.com/docs/cli/reference/#cache-item-and-vault-information}",
+  title        = {{ Cache item and vault information }},
+  year         = {2025},
+  note         = {Zugriff: Februar 2025}
+}