From 077eb803a16b3c4aa3439912b71352dda2539eda Mon Sep 17 00:00:00 2001
From: Gerhard Hoffmann <g.hoffmann@atb-online.eu>
Date: Sun, 16 Jul 2023 18:31:15 +0200
Subject: [PATCH] plan fuer das update

---
 allgemein.txt | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 126 insertions(+)
 create mode 100644 allgemein.txt

diff --git a/allgemein.txt b/allgemein.txt
new file mode 100644
index 0000000..6b2561e
--- /dev/null
+++ b/allgemein.txt
@@ -0,0 +1,126 @@
+0:
+    Zunaechst wir immer nachgesehen, ob das Repository bereits geklont wurde.
+    Wenn nein, dann wird geklont. Im Master-Branch befinden sich Dateinen, die
+    in allen anderen Branches gemeinsam genutzt werden. Das sollte wohl auf
+    jeden Fall fuer den DeviceController gelten.
+1:
+    Anfrage bei ISMAS ob neue Daten da sind. Hier faengt die ganze Sache an.
+    Da man nicht weiss, on ISMAS ueberhaupt antworten wird braucht es einen
+    Timer. Man kann die Sache dann auch gleich mehrfach versuchen.
+
+    Die Anfrage geht also per Signal an den Apism-Client. Im Signal wird der
+    Zustand mitgegeben:
+
+        ISMAS_UPDATE_REQUEST_PENDING
+
+    und im Slot dann entsprechend uebernommen. Der Timer sollte nicht im Worker
+    stehen, sondern im Apism-Client. Der Worker sollte damit nicht belastet
+    sein. Der wird dann vom Apism-Client entsprechend benachrichtigt.
+
+        ISMAS_UPDATE_REQUEST_FAILURE
+            ISMAS_UPDATE_REQUEST_TIMEOUT
+        ISMAS_UPDATE_REQUEST_SUCCESS
+
+    Im 1./2.Fall wird dann ein Fehlerhandling durchgefuehrt. Insbesondere
+    wird Apism ueber den DB-Kanal darueber informiert (U0003). Am Ende wie
+    dann wie immer SendCmdVersion und beenden der Applikation.
+
+    Im Erfolgsfall muss in der Antwort der Branch enthalten sein, fuer den das
+    Update durchgefuhrt werden soll. Das ist auch bereits so (Location).
+
+    Ein Sonderfall waere der -m-Modus, da hier niemand auf der ISMAS-Seite
+    aktiv eingreift. Hier braucht es dann einen Ubergabeparameter an 
+    ATBUpdateTool: --branch-name
+
+    Normalfall ist aber die Aktivierung via ISMAS. Dann muss der in der Antwort
+    enthaltene Branch zunaechst ausgecheckt werden.
+2: 
+    Dazu wird ein entsprechendes Signal an den GitClient gesandet.
+        
+        GIT_CHECKOUT_BRANCH_REQUEST
+
+    Der GitClient sieht jetzt erstmal nach, ob es diesen Branch ueberhaupt
+    gibt.
+
+        Falls nein:    
+
+        GIT_CHECKOUT_BRANCH_REQUEST_FAILURE
+            BRANCH_NOT_EXIST
+ 
+        Falls ja:
+            der GitClient versucht nun den Branch auszuchecken. 
+            Geht das gut?
+            Falls nein:
+
+                GIT_CHECKOUT_BRANCH_REQUEST_FAILURE
+                    BRANCH_CHECKOUT_ERROR
+
+            Falls ja:
+                GIT_CHECKOUT_BRANCH_REQUEST_SUCCESS
+                    -> eventl. koennte man den Namen des Branches mitgeben
+
+
+        Signal an den Worker. Im entsprechenden Slot wird jetzt der eigentliche
+        UpdateProzess angeworfen.
+ 3:
+    Mittels git fetch werden jetzt die Aenderungen ermittelt.
+
+        GIT_FETCH_UPDATES_REQUEST
+        
+        GIT_FETCH_UPDATES_REQUEST_FAILURE
+            -> Worker informieren damit Fehlerbehandlung aktiviert wird
+        GIT_FETCH_UPDATES_REQUEST_SUCCESS
+
+        GIT_DIFF_UPDATES
+
+        Die Liste der geaenderten Dateien geht an den Worker. Der kann jetzt
+        noch Test machen, ob das Sinn macht. Evtl. eine Statusmeldung ausgeben
+        drueber was gleich passieren wird.
+4:
+    Mittels git merge/pull werden nun die Dateien tatsaechlich im Branch 
+    aktualisiert.
+
+        GIT_PULL_UPDATES_REQUEST
+        GIT_PULL_UPDATES_REQUEST_FAILURE
+            -> Worker informieren damit Fehlerbehandlung aktiviert wird
+        GIT_PULL_UPDATES_REQUEST_SUCCESS
+            -> Worker informieren
+
+    Sind die Daten vorhanden, dann werden sie mittels rsync ins Dateisystem
+    kopiert.
+
+        RSYNC_UPDATES 
+        RSYNC_UPDATES_FAILURE
+        RSYNC_UPDATES_SUCCESS
+
+    Fuer jede kopierte Datei geht eine Nachricht raus ans ISMAS.
+5:
+    Sind die Daten dann kopiert, so werden sie auf den DC kopiert (falls
+    notwendig): hier gehen dann wieder Nachrichten an ISMAS raus:
+
+        DC_UPDATE 
+        DC_UPDATE_FAILURE
+        DC_UPDATE_SUCCESS
+
+        JSON_UPDATE
+        JSON_UPDATE_FAILURE
+        JSON_UPDATE_SUCCESS
+        
+        Hier fuer jedes Json-File.
+
+    Schliesslich noch eine Zusammenfasung an ISMAS:
+
+        ISMAS_UPDATE_INFO_CONFIRM
+        ISMAS_UPDATE_INFO_CONFIRM_FAILURE
+            -> Worker informieren damit Fehlerbehandlung aktiviert wird
+        ISMAS_UPDATE_INFO_CONFIRM_SUCCESS
+
+    und schliesslich der abschliessende Status an ISMAS zurueckgemeldet:
+
+        ISMAS_CURRENT_PSA_STATUS_CONFIRM
+        ISMAS_CURRENT_PSA_STATUS_CONFIRM_FAILURE
+        ISMAS_CURRENT_PSA_STATUS_CONFIRM_SUCCESS
+
+    
+
+