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.