Added: Text to concepts

docs/concepts/actorinitiator.md

@@ -1,2 +1,8 @@
 # Actors and Initiators
+Um FabAccess erweiterbar zu halten, basiert die Steuerung externer Geräte wie WLAN-Steckdosen oder Türschlösser auf einem Aktoren- und Initiatorskonzept.
 
+## Aktoren
+Aktoren in FabAccess haben die Aufgabe, die digitalen Zustände von Ressourcen in reale Zustände umzusetzen. Vom Server aus werden die Übergänge der Traits an kleine Skripte oder Prozesse weitergegeben, die entsprechend darauf reagieren.
+
+## Initiatoren
+Mit Initiatoren werden reale Zustände auf die digitalen Zustände in FabAccess abgebildet. Zum Beispiel können Türkontakte den aktuellen Zustand der Tür übertragen, und FabAccess kann entsprechend darauf reagieren.

docs/concepts/auth.md

@@ -1,5 +1,8 @@
 # Authentication
+Das Authentifizieren in FabAccess basiert vollständig auf SASL und unterstützt daher verschiedene Mechanismen.
 
 ## OAuth
 
-## LDAP
+## LDAP
+
+## FabFire

docs/concepts/cachable.md

@@ -1 +1,6 @@
 # Cache Data
+In FabAccess gibt es eine Unterscheidung zwischen statischen und dynamischen Daten, die von Ressourcen besessen werden.
+
+Dynamische Daten umfassen Zustände oder Messwerte, die von Ressourcen erzeugt werden.
+
+Statische Daten hingegen sind Eigenschaften, die sich nicht regelmäßig ändern, sondern nur in größeren zeitlichen Abständen. Diese statischen Daten werden in FabAccess zwischengespeichert, um die Antwortzeiten des Servers zu reduzieren und Ressourcen in Clients schneller anzeigen zu können.

docs/concepts/capnp.md

@@ -1 +1,8 @@
-# Capn Proto API
+# Cap'n Proto API
+Die API von FabAccess basiert auf Cap'n Proto. Cap'n Proto wird verwendet, um eine erweiterbare und bidirektionale API bereitzustellen. Dank der Codegenerierungsfunktion von Cap'n Proto kann die API in jede Programmiersprache portiert werden. Jedes Interface wird in einer übersichtlichen Schema-Sprache dargestellt, was die API selbst dokumentierend macht. Die Verfügbarkeit von Interfaces im Client kann durch einfache Null-Checks überprüft werden.
+
+Um einen übergeordneten Zugangspunkt zu bieten, ist die API in Systeme unterteilt, die erweitert und ausgetauscht werden können. Der Einstiegspunkt in die API ist das Bootstrap-Interface, das jedem Client angeboten wird. Nach der Authentifizierung werden die für den Client relevanten Interfaces bereitgestellt.
+
+Die API soll anderen Clients oder Skripten einen stabilen Zugang zu Ressourcen ermöglichen und die Zusammenarbeit zwischen Systemen fördern. Der Server entscheidet selbst, welche Ressourcen und Interfaces er den Clients zur Verfügung stellt, je nach Berechtigung und Konfiguration. Die Clients müssen daher in der Lage sein, damit umzugehen.
+
+Durch die API und die damit verbundenen Anforderungen soll der Zugang zu Ressourcen für alle erleichtert und die Zusammenarbeit gefördert werden. Diese Grundlagen sollen dazu beitragen, ein föderiertes System für den Ressourcenverleih aufzubauen.

docs/concepts/fabfire.md

@@ -1 +1,2 @@
-# FabFire
+# FabFire
+FabFire ist eine Entwicklung, die auf NXP Mifare DESFire basiert und die Anwendung von Karten nutzt, um Benutzer über das Over-the-Air (OTA)-Verfahren zu authentifizieren.

docs/concepts/urlurn.md

@@ -1 +1,4 @@
-# URL and URN
+# URL and URN
+Ressourcen in FabAccess werden durch einen Namen dargestellt. Um jedoch die Suche nach Ressourcen zu verbessern, können diese Referenzen als URN (Uniform Resource Name) oder URL (Uniform Resource Locator) geschrieben werden.
+
+Die URN ist ein Identifikator ohne Bezug zum Space, während die URL auch den Space referenzieren kann, um einen Austausch von Ressourcen zu ermöglichen.