monitor 1.9.0 - aber richtig :)

[jhr-online]

Wenn ich noch mal was technisches reinwerfen darf:
Wie wäre es damit, wenn ich sich einer derjenigen, die auch wirklich verstehen, was hier geplant ist, mal dranmachen würde, das ganze etwas systematisch im Wiki aufzuarbeiten. Der Thread wird langsam unübersichtlich - die ersten beklagen sich :)
Da ich am Code nicht viel mitarbeiten kann, bin ich gerne bereit, mich weiter in dieses organisatorisch reinzuhängen, aber den ersten Schritt muss wirklich jemand machen, der das alles versteht... Die Vorschläge auseinanderhalten und das, was zusammen gehört, auch zusammen zu formulieren; Backend- von Frontend-Vorschlägen trennen etc.

Hat jemand Lust? Hier geht's los:
http://monitor.08k.de/index.php/Devel bzw. eigentlich erst
hier: http://monitor.08k.de/index.php/Devel/2.0

jhr

Nachtrag: Ich muss ja nicht alles selber machen und auf meinem PC horten... :) Tragt euch ein: http://monitor.08k.de/index.php/Devel/Team

[Norad]

Moin, ich mische mich hier auch mal ein :)
Mir scheint, dass die Komplexität hier gerade explodiert ;)

Ich würde mir das so vorstellen:
monitor-backend: nimmt Daten von der Soundkarte und stellt diese Dekodiert über TCP zur Verfügung. Kein Logging, keine Datenbank.

Frontends: z.B. Daten in eine Datenbank schreiben, Daten in ein Log schrieben usw.
Ein GUI- (oder Textkonsolen-) Frontend würde aktuelle Ereignisse direkt vom Monitor-Backend bekommen und könnte die Historie entweder direkt aus der Datenbank des DB-Frontends abrufen oder evtl. mit dem DB-Frontend kommunizieren. Für den Direktzugriff auf die DB müssen GUI- und DB-Frontend sich bloß auf eine Datenbankstruktur einigen, für die andere Variante müsste man ein Protokoll entwerfen ...

[nepomuck]

Für den Direktzugriff auf die DB müssen GUI- und DB-Frontend sich bloß auf eine Datenbankstruktur einigen

Das ist ein wunder Punkt. Ich habe mir gerade die Datenbankstruktur des aktuellen MySQL-Frontends angesehen. Die Tabellen werden wir so nicht beibehalten können. Bislang übernimmt ja der Monitor eine Reformatierung und Filterung der Events. Das ist künftig nicht mehr der Fall da das Backend die Rohdaten in die SQL-Datenbank schickt. Dazü genügt im Prinzip seine sehr einfache Datenbankstruktur.

Soll ich mir da mal was ausdenken, oder möchte das lieber einer der Frondend-Entwickler tun, der später später seine Anwendung an die DB andocken muss?

Andreas

[MiThoTyN]

Morsche zusammen!

Also bei der Diskussion eben zum Thema Datenbank ist mir auch bischen schwindelig geworden. Die Komplexität ist in der Tat explodiert. Da müssen wir nochmal ansetzen an der Ecke.

Also einig darüber, dass der monitor keine DB-Anbindung hat und auch keine Log's schreibt sind wir uns?

Es bleibt jetzt nur zu klären, wie eine Datenbank an den monitor angebunden wird und wie entsprechende GUI's dann auf die Datenbank zugreifen können.

Mein Vorschlag wäre folgender :

Variante 1 : Es ist keine DB installiert

Sämtliche Clients (GUI's bzw. Frontends) verbinden sich direkt an den monitor. Da der monitor keine Benutzerverwaltung hat, gibt es nur einen Standarduser zum Verbinden. monitor und Frontend unterhalten sich über das "normale" Monitor-Datenprotokoll. Nachteil ist, dass der Client nur die Live eingehenden Daten anzeigen kann, da es ja eben keine Datenbank gibt. Für eine SMS-Alarmierung oder ähnliches ist dieser Zustand aber durchaus in Ordnung, da hier eh keine History-Daten interessieren.

Variante 2 : Es gibt eine DB-Middleware

Eine entsprechende DB-Middleware hat sich per TCP an den monitor angedockt und bekommt von dort die Rohdaten, um diese in die Datenbank zu schreiben. Sämtliche Frontends verbinden sich nun mit dieser DB-Middleware direkt, die nach außen hin jetzt als Backend fungiert. Sich über einen zweiten Kanal nochmal mit dem monitor verbinden halte ich für sinnlos, da alle Daten vom monitor eh an die Datenbank geschickt werden. In der Datenbank sind jetzt verschiedene Benutzerkonten und Benutzerrechte konfigurierbar und die Frontends können per Sessionhandling überwacht und gesteuert werden. DB-Middleware und Frontends unterhalten sich jetzt auch über das Monitor-Protokoll, welches um Befehle für den Datenbankzugriff (History) erweitert wurde. So kann ein Frontend jetzt aus der Datenbank z.B. die letzten 100 Statis eines Fahrzeugs abfragen o.ä.

Prinzipiell bleibt egal bei welcher Methode zu klären, WAS genau die Datenbank speichert und was man Abfragen kann. Reicht es die Daten in einer Tabelle als Rohdaten abzulegen oder muss/soll/kann die DB-Schicht schon erste Auswertungen vornehmen und die Daten in unterschiedliche Tabellen speichern? (Letzter Status eines Fahrzeugs z.B.) Und welche Funktionen kann ein Frontend dann von der DB benutzen? Gibt es vorgefertigte Funktionen wie "HoleLetzteXXEinträge" oder gestalten wir das so flexibel, dass man SQL-Anfragen an die Datenbank schicken kann?

Gruß Joachim

PS.: Heut Abend kommt irgendwann ne erste Protokollversion.

[MiThoTyN]

Hier meine Vorlage zum Protokoll. Ich denke es ist soweit alles grundsätzliche drinne erstmal. Über die Befehlsliste müsst ihr mal drüber gucken. Fürn Anfang sind mir nicht mehr eingefallen. Wenn wir uns dann über einen Mindestsatz an Befehlen geeinigt haben, mach ich Punkt 6 ausführlich. Dann bekommt jeder Befehl ne eigene Beschreibung.

Soweit erstmal!

Gruß Joachim

[Buebchen]

Hi MiThoTyN,

ich habe mir das Protokoll seit mal angeschaut. Ist doch ein wenig anders als z.B. SMTP, da die erste Ziffer nicht "Info, Warnung, Fehler" signalisiert, sondern direkt spezifisch auf die genutzten Funktionen eingeht.

Wenn man (bzw. ich) das kapiert hat, dann versteh' ich das ganze soweit auch. Einiges ist auch für die Zukunft noch frei. Werde das - sobald ich an dem Punkt bin - also mal anfangen umzusetzen. Dabei ergeben sich zwangsläufig weitere Fragen. Aber die Struktur ist ja nun klar.

[jhr-online]

Du willst anfangen umzusetzen, also Code zu produzieren? Hälst du es nicht für besser, erst dafür zu sorgen, dass das Konzept allen willigen Entwicklern klar ist und dann ein wenig abzusprochen, wie entwickelt werden soll und wer was macht und so?

jhr

[nepomuck]

Hier meine Vorlage zum Protokoll.

Danke für die Mühe und den Entwurf

Ich hätte da noch ein paar Punkte anzumerken:

Befehle 101,201 Error, Datenfelder 0
Ein Error ohne Beschreibung hilft in der Regel nicht weiter. Ich empfehle, dass wir dem Befehl ein Datenfeld mit einem Fehlercode anhängen und in der Protokolldefinition fehlercodes deklarieren, Beispiel:

101:001
Error:Server kann auf Sounddevice nicht zugreifen
101:034
Error:Benutzeranmeldung fehlgeschlagen
201:124
Error:Client unterstützt Protokollversion nicht

Dazu auch ein Vorschlag für ein weiteres Kommando:
111 Versionsnummer (Serverversion)
112 Protokollversion

Befehle 330,430 DTFM
Da sollten wir klären, ob wir diese Befehlsgruppe überhaupt brauchen. DTFM kommt sowieso nur in Verbindung mit einer ZVEI-Alarmierung vor, daher könnte man den DTFM-Code direkt mit der ZVEI-Alarmierung übertragen. Das hätte den Vorteil, dass der Client nach einem 5-Ton Alarm nicht eine gewisse Zeit warten muss, ob noch eine DTFM-Anweisung folgt oder nicht.

inklusive Trennzeichen und Zeilenende nicht länger als 512 Byte ist.

Da sollte bitte mal jemand, der sich mit FMS auskennt prüfen, wie lange Folgetelegramme sein dürfen. Da könnten 512 Byte evtl nicht reichen, vor allem, da wir die textmeldung hex codieren und daher pro character zwei Byte brauchen.

Andreas

[Fernmeldedienst]

Hallo!

Kann zwar leider nicht programmieren..

aber hätte da noch 2 Vorschläge...

das wäre zum einen die Einbindung des FMS-AuftragsText der Leitstelle

und zum anderen die Positionsmeldungen der einzelnen Fz an die Leitstelle via GPS (Stat 10)

73,

Daniel