#71 Zentralisierte Treffenkonfiguration
Bisher ist es so, dass jede RgZm auf eine lokale auf dem Rechner befindliche Konfiguration angewiesen ist. Das kann dazu führen, dass auch mal versehentlich eine ältere Konfiguration geladen wird, weil beim Kopieren ein Fehler vorlag. Außerdem müssen für kurzfristige schnelle Änderungen bei mehreren Betriebsstellen immer genau diese auch lokal eingepflegt werden. Das ist umständlich und fehleranfällig.
Geplant ist daher eine zentralisierte Treffenskonfiguration auf Basis des grafischen Treffenskonfigurator bzw. dem Dispatcherarbeitsplatz. Dabei liegt die Konfiguration exakt nur einmal vor und jede gestartete RgZm Instanz verbindet sich mit diesem zentralen System und lädt sich die jeweils aktuell gültige Konfiguration über das Netzwerk.
Denkbar wäre zusätzlich noch, dass neben der Treffenskonfiguration auch gleich die Möglichkeit des Downloads des RgZm-Pakets angeboten wird. Dazu muss die Anwendung einen Webserver zur Verfügung stellen, welche mit dem Browser aufgerufen werden kann.
Dieses Feature müssen wir möglichst genau spezifizieren. Zuerst mal die Konfiguration. Ich gehe davon aus, dass im Netz dann ein Dienst gestartet wird, der (über XmlRpc) die Config bereit stellt. Der Service macht sich wie bei RgZm üblich über Multicast bekannt.
Jetzt geht es los mit der Startroutine. Aktuell popt ein Dateimenü auf um die Konfig zu laden, Der Dateiname kann aber auch als Parameter mitgegebn werden.
Fall 1: es ist keine Konfig im Parameter angegeben worden, beim Start (Wartezeit nötig!) wurde der Service lokalisiert. Kommt jetzt eine Auswahl, ob ein Dateidialog oder die Netzkonfig geladen werden soll? Bauen wir einen koplexen Dialog, der die Netzkonfig anzeigt und die Dateiauswahl? Dabei wäre zu beachten, dass es mehrere Netzkonfigs geben kann. Zb bei Großtreffen wie Riesa. Da hatten wir 2 TT-Arangements und noch eins für N, das per RgZm betrieben wurde.
Wenn dann eine lokale Konfig gewählt wurde, ist klar, dass auch die BFO von lokal geholt wird. Wie aber beim Laden der Konfig vom Netz? Die BFO kann nun auch von dort geladen werden. Da aber die BFO auch per RgZm geschrieben wird, sollte dann auch zum Service geschrieben werden? Was wenn der nicht erreichbar ist? Hier kommt man ganz schnell in Probleme einer Versionsverwaltung. Denn wird lokal geschrieben, hab ich 2 BFOen, die konkurieren. Die aktuellere nehmen, oder noch mal auswählen lassen? Noch komplexer wird es durch den Parameter der Betriebsstellenauswahl beim Start von RgZm.
Wichtig ist ja vor allem, dass wir die Nutzer mit dem ganzen technischen Schnickschnack verwirren.
Es zeigt sich sehr anschaulich, dass sowas in Gedanken Simples schlussendlich sehr komplex wird oder werden kann. Das erinnert mich ganz stark an den Package Builder für Treffen...
Aus meiner Sicht zunächst: Sofern es im Netz keinen Service gibt, wird gleich der Dateidialog zum Laden einer lokalen Datei geöffnet.
Ist ein Service vorhanden, sollten in einem Pull-Down Menü die zur Verfügung gestellten angezeigt werden. Zusätzlich darunter ein Durchsuchen Button zum Laden einer lokalen Konfig.
Eine Remote geladene BFO würde ich auch dorthin wieder zurückschreiben. Dazu ist natürlich ein robustes Kommunikationsprotokoll notwendig/Voraussetzung. Notfalls müssen die Änderungen lokal gecacht und später zurück geschrieben werden.
Nehmen wir einmal an, es soll einen Service geben und die RgZm soll über diesen gleich die entsprechende Konfig und auch BFO einer bestimmten Betriebsstelle laden. Steht der Service aufgrund von Netzwerkproblemen nicht zur Verfügung, so muss eine Fehlermeldung an den Benutzer erfolgen. Dann muss dieses Problem erst gelöst werden. An dieser Stelle darauf zurückzufallen, plötzlich einen Dateidialog anzubieten würde nur verwirren.
Ansonsten stimme ich deinen Überlegungen zu.