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.