monitor 1.9.0 - aber richtig :)

[Buebchen]

Hallo,
[...viel Text:-) ]

Ja, ich bin begeistert von SQLite, entschuldigung ;).

Ich kenne SQLite nicht. Aber ich suche noch eine effektive Methode um die Nachrichten vom Decoder zu den Socketthreads zu queuen oder spoolen. Könnte man nicht sogar eine SQListe-DB (oder mehrere) nehmen ?

Da es ja auch bei der Nutzung von SVN gewisse Standards gibt, möchte ich hiermit vorschlagen, dass /trunk nach /branches/1.9.0 gemoved wird (als Archiv, damit es nicht wegkommt, quasi). Entsprechend ist /trunk dann leer und kann mit den Daten des aktuellen Branches (/branches/2.1.1-mergeWinLin) gefüllt werden, wobei dann hoffentlich keine wichtigen Änderungen aus den anderen 2er-Branches verloren gehen (gut, man könnte nochmal diff-en und nötigenfalls mergen). Damit wäre im /trunk die aktuelle Version 2.0 (ohne die 1en und das mergeWinLin am Ende - brechen wir es auf das eigentliche Ziel herunter), die dann als Feature-Set hat: Plattformunabhängigkeit, Funktionalität (Erkennung, Ausgabe über die drei Sockets in drei Formaten Crusader, FMS32, monitord).

Kann ich nur unterstützen. Sofern nichts dagegen spricht werde ich mit jhr-online absprechen, daß wir mal umsetzen. Ich habe auch schon nem Test-PC ohne drauf zu achten den trunk ausgecheckt und war doch etwas verwundert...

Einen Branch/Branches für die 2.1 oder 2.2 (HTTP-Engine, MySQL-Engine, was auch immer) anzulegen, wäre dann sicher sinnvoll, sobald ein neues Feature implementiert werden soll. Ich möchte auch die Nutzung von Tags anregen, mit denen man ja ganz famos Revisionen im SVN Versionsnummern von Software aufklatschen kann, so dass nach einer Umstrukturierung wie vorgeschlagen direkt der Inhalt von /trunk in /tags/2.0-291107 als lauffähige Version markiert werden könnte und sollte, um lauffähigen Code schnell und einfach auscheckbar zu haben.

Kann ich auch so unterstützen.

@Buebchen: Die Sache mit dem Überarbeiten der Storage-/Display-Module und dem "Übersehen" unbekannter Parameter finde ich sehr sinnvoll.
Allerdings fiel mir dazu ein: Warum sollte man nicht die Nachrichten, die von den Auswertern kommen, in eigene Objekte kapseln? Damit könnten die Nachrichtenpakete vom Typ "ZVEImsg", "POCmsg" und "FMSmsg" sein, auch wenn sie dann vielleicht nur Attribute enthalten (Datencontainer eben). Damit würde es die Ausgabe-Methoden geben "Output(ZVEImsg out)", "Output(POCmsg out)" und "Output(FMSmsg out)". Das würde auch ein ähnliches Verhalten abbilden wie Du schriebst: Zusätzliche Attribute der Datenobjekte würden zwar bestehen aber nicht ausgegeben (weil die Methode das Feld nicht kennt und eben nicht darauf zugreift - aus die Maus), ohne dass große Eingriffe in den Code (speziell die Definition der Ausgabemethoden) notwendig wären.

Viele Grüße
Martin

Details zur Umsetzung sind noch ganz offen. Ich denke der Datentyp map<std::string,std::string> hat halt den Charme, daß man ihn wie ein PHPArray ansprechen kann. Das ganze kann ja dann auch Element einer der Klasse wie bei Dir beschrieben sein. Das ganze dann von einer BASEmsg abgeleitet könnte doch recht zukunftssicher sein.

Ob drei Ausgabemodule mehr oder weniger Sinn machen als eine einzelne Output-Funktion muss ich mal überlegen.

[jhr-online]

Um's nicht zu kompliziert zu machen:

Ich bin voll einverstanden und übergebe hiermit mal ausdrücklich buebchen die ehrenwerte Aufgabe, die Änderungen durchzuführen. Vielleicht sollten die Schreiberlinge kurz vom svn die Finger lassen bis buebchen hier die Durchführung bekannt gibt.
Okay?

jhr

[Buebchen]

trunk ist jetzt die 2.1.1-merginwin.

Die alten branches habe ich in den Ordner branches/discontinued verschoben.
Der alte trunk ist jetzt tags/1.9.0

Hab ich jetzt noch was vergessen ?

[nepomuck]

Eine kurze, organisatorische Bitte:

Da Ihr offensichtlich gerade mehr unter Windows als unter Linux am Entwickeln seid, fehlt sämtlichen Skripten im SVN das Executable-Flag. Wer den Code unter Linux übersetzen will, muss zunächst einmal in alle Dateien reinschauen und herausfinden, was per chmod +x umgestellt werden muss..

Könntet Ihr bitte alle ausführbaren Skripte so umbennennen, dass sie auf ".sh" enden. Dann genügt es, ein einziges "chmod +x *.sh" zu fahren.

Danke,
Andreas

[nepomuck]

OK: Ich habe jetzt folgendes unter Ubuntu 7.10 32-Bit gemacht:

sudo aptitude install build-essential
sudo aptitude install tofrodos
chmod +x configure config.sub install-sh config.guess
dos2unix config.sub
dos2unix config.guess
./configure

Das bringt mich zumindest schon mal bis hier:

checking if PIC flag -fPIC works... no
checking if supports -c -o file.o... no
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... ./configure: line 14490: -print-search-dirs: command not found
GNU/Linux ld.so
checking for ALSA CFLAGS...
checking for ALSA LDFLAGS... -lasound -lm -ldl -lpthread
checking for libasound headers version >= 0.9.1... not present.
checking for snd_ctl_open in -lasound... no
configure: creating ./config.status
.infig.status: error: cannot find input file:

Was geht hier schief?

Andreas

[mdi]

Hallo,

ich habe gleich mal ins SVN geschaut eben und schonmal eine sehr angenehme und nachvollziehbare Ordnung gefunden :). Toll, danke!

Ich möchte Dich, Buebchen, aber noch bitten, den /tags/1.9.0 zu einem /branches/1.9.0 zu verschieben, da die Tags (rein interpretativ) als "Kennzeichnungspunkte" (in der Regel in Bezug auf /trunk) verstehbar sind und die 1.9-er ja nicht mehr im /trunk entwickelt wird (und an sich auch nie wurde). Im /branches könnte (so jemand wollte) dann auch noch an der 1.9er geschraubt werden (in /tags sollte ja grundsätzlich eher nicht entwickelt werden, wenngleich es dem SVN prinzipiell egal ist, wo was liegt - die Bedeutung interpretiert der Mensch ja hinein).

Außerdem wäre in meinen Augen gleich ein Tag /tags/2.0-301107 gut, um lauffähige Versionen nach größeren Änderungen der aktuellen Entwicklung zu markieren. Der jetzte Stand in /trunk ist (jedenfalls war er es gestern noch ;)) lauffähig und kann daher meiner Meinung nach gut entsprechend als "offizieller Anfang der 2.0" markiert werden. Gut, die Probleme, die nepomuck hier schildert, sollten wir vielleicht vorher noch im Griff haben.

Danke für die Mühe :)!
Martin

[mdi]

Hallo,

Ich kenne SQLite nicht. Aber ich suche noch eine effektive Methode um die Nachrichten vom Decoder zu den Socketthreads zu queuen oder spoolen. Könnte man nicht sogar eine SQListe-DB (oder mehrere) nehmen ?

ja, das könnte man.
SQLite ist eine SQL-Datenbank auf Dateibasis (ein File - eine Datenbank), die mit dem Dateinamen ":memory:" auch rein im Speicher (entprechend flüchtig) Daten halten kann. Das ist allerdings in dem Fall glaube ich nicht so praktisch, da der gesamte Datenbank-Overhead dazu käme, was hier ja nicht nötig wäre.
Wenn aber die Geschichte mit den *msg-Objekten realisiert wird - dann könnte doch einfach eine Datenstruktur (Array, verkettete Liste, ...) die *msg-Objekte pro Thread halten (hält der Thread selber oder soll das gebündelt vor der Übergabe an die Threads passieren?).

Änderung I:
Ich habe mal das anhängende Bild gemalt... ZVEImsg, POCmsg und FMSmsg sind abgeleitet von BASEmsg. Die Display- und Storage-Master sind quasi die Manager der Ausgabe-Module (sprich sie halten eine Liste der bestehenden Display/Storage-Module und geben die eingehenden Nachrichten *msg an die einzelnen Module weiter, können die auflaufenden Nachrichten aber auch queuen, falls bei den Modulen ein Problem auftritt - pro Modul wäre da eine Queue sinnvoll, damit bei fehlerhaftem Verhalten eines Moduls die anderen noch sauber weiterarbeiten können). Ich würde dann bevorzugen, pro Modul eine eigene Ausgabe-Routine pro *msg-Subtyp einzusetzen, damit erst im spezifischen Modul die Ausgabe-Formatierung geschehen muss. Die hier als einzelne Manager gezeichneten "Dinger" könnten auch zu einem Manager zusammengefasst werden, ebenfalls könnte der Manager eine Queue für eingehende *msg haben und die Ausgabemodule bei Bedarf eine eigene Queue halten (das wäre beim HTTP-Push nicht schlecht, weil Antwortzeiten zu berücksichtigen sind, beim monitor-Socket ist das wiederum nicht so wichtig, weil hier keine Zeitgeschichten/Feedbacks zu berücksichtigen sind).

Änderung II:
Mir fiel beim Einkaufen ein, dass genau im Manager (als dem "Sammler" für *msg-Objekte) auch die History-Geschichte (dann gerne in Form einer SQLite-Datenbank im Speicher oder in einer Datei) zu implementieren sinnvoll wäre, das nur als Ergänzung dazu.

Martin

[Buebchen]

Hallo,

Wenn aber die Geschichte mit den *msg-Objekten realisiert wird - dann könnte doch einfach eine Datenstruktur (Array, verkettete Liste, ...) die *msg-Objekte pro Thread halten (hält der Thread selber oder soll das gebündelt vor der Übergabe an die Threads passieren?).

Im Moment sind es getrennte Listen (std::list) pro Thread. Geht auch soweit. Ich würde sie dann ggf. nur denmächst mal in eine Klasse einbetten, da ich immer auch über eine Semaphore sicherstellen muss, da immer nur ein Prozeß die Liste ändert. Nach meiner Meinung müssen die Objekte pro Thread in eine eigene (private) Queue. Sonst könnte ich erst das Element aus der zentralen Queue entfernen, wenn alle Threads es abgearbeitet habe (was dann synchronisiert werden müßte).

Änderung I:
..., können die auflaufenden Nachrichten aber auch queuen, falls bei den Modulen ein Problem auftritt - pro Modul wäre da eine Queue sinnvoll, damit bei fehlerhaftem Verhalten eines Moduls die anderen noch sauber weiterarbeiten können ...

Martin

So in der Art würde ich mir das auch vorstellen können. Dann sollten wir einen Dispatcher als Dreh- und Angelpunkt für die Nachrichten vorsehen. Dieser bedient dann bei ihm registrierte Module (Füllt deren privaten Queues - ggf aber nur bis zu einem Limit von vielleicht 100 Einträge). Ich wüßte im Moment nur nicht, warum ich für Display und Storage verschiedene Dispatcher brauche. Die Daten sind identisch - nur die spätere Verarbeitung nicht. Wenn jedes Modul - wie es schon beim SocketThread ist - seine eigene Queue könnte man die StorageModule genauso behandeln.

[Buebchen]

Ich habe nun begonnen, noch einen Dispatcher für die Nachrichten der Auswerter zu schreiben.

Vom Ablauf stelle ich mir es dann so vor:

1. Modul meldet Daten in einem einheitlichen Format (z.B. std::map) an Dispatcher (z.B. FMS Auswertung)
2. Dispatcher (eigener Thread, Auswerter läuft also ohne Unterbrechnung weiter) verteilt Daten an SocketServer und Plugins (Jeweils eigene Threads)
3. SocketServer und Plugins erstellen dann für sich die passenden Strings, die dann weiter verarbeitet werden (SocketServer an die einzelnen SocketThreads)

[mdi]

Hallo,

ich habe immernoch ein Problem mir vorzustellen, was und warum genau mit dem <std::map> gearbeitet werden soll :7.

Die Sache mit den Datenobjekten finde ich da einfacher, weil (wie geschrieben) dann eine Oberklasse BASEmsg ausreicht, um egal welche Daten überall im Kern durchzuschieben ohne sich um die innere Struktur kümmern zu müssen (braucht da ja auch niemand).

Vielleicht könnte man es dann auch sinnvoll implementieren, dass diese Daten-Objekte ihre eigene "getFMSProData", "getmonitordData", "getCrusaderData"-Routine mitbringen, so dass die Aufbereitung der Daten für die verschiedenen Ausgabeformate der Kernfunktionalität des monitord prinzipiell dem Autor der jeweiligen Auswerter- bzw. Datenobjekt-Klassen obliegt aber frei anpassbar ist für kommende Entwicklungen ohne dass die Ausgabe-Klassen extra angefasst werden müssen (die bekommen dann ein Datenobjekt BASEmsg bzw. dessen Ableitung in z.B. FMSmsg, und fordern es auf, seine Daten selber sinnvoll auszugeben bzw. sie sinnvoll formatiert als String an das Ausgabemodul zurückzugeben).

Hm... ja. So weit.
Martin

[Buebchen]

Hallo,

ich habe immernoch ein Problem mir vorzustellen, was und warum genau mit dem <std::map> gearbeitet werden soll :7.

Die Sache mit den Datenobjekten finde ich da einfacher, weil (wie geschrieben) dann eine Oberklasse BASEmsg ausreicht, um egal welche Daten überall im Kern durchzuschieben ohne sich um die innere Struktur kümmern zu müssen (braucht da ja auch niemand).
Martin

Ich glaube, die abgeleiteten Klassen mit klassischen Membervariablen finde ich in sofern unflexibel, daß jedes neue Feld dann im Source-Code hinzugefügt werden muss, bevor man es verwenden kann. Eine dynamische Struktur wie die map hat hat so ein Problem nicht. Dennoch kann man die map ja in eine Klasse packen, die den Zugriff auf die Daten nochmal kapselt und überwachen kann. Hin- und herschieben kann man so eine Klasse auch ganz prima :-)

Wenn man irgendwann beschließt aus einem optionalen Backend (z.B. Datenbank) ein Feld "Fahrzeugname" in den Datensatz einzufügen wäre das möglich (Durch ein "PreDispatcher" Plugin könnten die Daten ergänzt werden.) Und das ohne, die Klassendefinition anpassen zu müssen. Gleiches gilt dann für ein vorhandenes StorageModul. Es kann die ergänzten Daten lesen und nutzen, wenn es sie abfragt. Und das alles ohne SourceCode Änderung. Und andere Module sind davon unbeeindruckt.

Da fallen mir einige Möglichkeiten ein, um den monitord an ganz verschiedene Bedürfnisse anzupassen. Ich z.B. fände es toll, wenn ein Fahrzeugname schon vor dem Weiterleiten an die Clients ergänzt wird. Oder z.B. auch der POCSAG-Text der letzten Alarmierung. Oder der vorherige Status (wenn es ein FMS Protokoll ist)...

Sagen wir also mal, daß ich denke die map ist kein Erschwernis (sofern man damit leben kann, daß alle Daten als String behandelt werden) sondern eine Option für die Zukunft :-)

[nepomuck]

Kurze Bitte:

Könnte einer von euch mal prüfen, warum bei mir nicht einmal das configure-Skript durchläuft? Ohne das kein make und ohne Make kann ich aktuell gar nichts testen.

Andreas

[mdi]

Hallo,

Sagen wir also mal, daß ich denke die map ist kein Erschwernis (sofern man damit leben kann, daß alle Daten als String behandelt werden) sondern eine Option für die Zukunft :-)

ja, da muss ich Dir (nachdem ich endlich verstanden habe, wozu die da sein soll - ich habe da total auf dem Schlauch gestanden) zustimmen, das ist sehr flexibel für mögliche Module, die die von Dir angebrachten Änderungen (Mapping Nummern->Namen, wie auch immer) durchführen. Das würde allerdings bedingen, dass wir drei verschiedene Arten von Modulen haben - Decoder, verarbeitende Module vor der Verteilung an die Ausgabemodule und eben diese Ausgabemodule, richtig?

Da möchte ich doch noch die Frage in den Raum werfen, ob eine derartige Datenzusammenführung nicht clientseitig oder durch eine Datenbank besser aufgehoben wäre.

@nepomuck:
Die Sirenentonerkennung sollte jetzt für alle möglichen Alarme funktionieren, allerdings werden alle zur Zeit noch als Typ 2 deklariert, wodurch der Subtyp nur im Klartext der Message erscheint (Sirenenauslösung: [Probe|Feuer|...]).

Martin