monitor 1.9.0 - aber richtig :)

[nepomuck]

Das, was wir hier so beschreiben und als Ideen ansammeln, ist aber alles für 2.0, richtig?

Ja. In den 1.x-Spaghetti-Code würde ich nur noch das Minimum an Arbeit investieren. Wenn sich schon ein paar Leute gefunden haben, die aktiv an dem Projekt weiter arbeiten möchten, dann sollten wir gleich die Modularisierung und damit Version 2 in Angriff nehmen.

Auch schön wäre ein grober Zeitplan,

Der dürfte in erster Linie von Buebchen abhängen, da er die eigentlichen Änderungen im Code durchführen muss. Ich bin hier leider nur eine kleine Hilfe, da ich keinen eigenen Code zusteuern kann

aber das sollten wir in den Chat verlegen

Muss das unbedingt im Chat sein? Ich bin da kein Freund davon weil's lange dauert und eigentlich nicht viel dabei rumkommt. Wie wär's mit einer VoIP-Telefonkonferenz, via Skype oder so?

weil wir dann wissen, welche Kapazitäten wir haben.

Fang doch schon mal eine Liste an:
Buebchen: Head of Development und Meister des Codes :-)
Nepomuck: Designvorschläge, schlau daherreden, Bugfixing, Testing, Dokumentation, Live-CD bauen.
Zudem kann ich, falls erwünscht, Web-Space und Internet/Speicher-Kapazität anbieten. Ich verfüge über eine 10 MBit/s Standleitung mit ein paar festen IP-Adressen und kann ins Internet hängen was ich will. Ich würde dazu passend einen oder mehrere (auch virtualisierte) Server stellen.

Es wäre auch vorstellbar, einen "Decoder" zu schreiben, der die Daten als mp3 Stream aufbereitet und dem Client direkt "live" senden.

Machbar ist viel. Wir sollten uns aber für die Version 2.0 nicht zu viel vornehmen. Ich würde diese Funktion als "Kür" einstufen, die "Pflicht" ist jedoch zunächst die grundlegende modularisierung und die Kommunikation Back-Frontend.

Ausserdem wäre dann noch zu klären, wie die Aufnahme zum Frontend kommt.

In der Version 2.0 soll sich da jemand anderes drum kümmern (NFS/SAMBA). Der monitord kann die Aufzeichnungen auf einem File Share sichern und das Frontend holt sie da ab. Stand heute gibt's im Frontend ja auch noch keinen integrierten Player. Das Streaming würde ich erst ein einer späteren Version berücksichtigen.

Ich würde das Konzept auch direkt auf mehrere Soundkarten erweitern. Warum nicht direkt zwei oder mehr Soundkarten ermöglichen ?

Das sollte das modulare Konzept ja ohnehin beherrschen. Das Frondend kann über den Control-Port problemlos Anweisungen für mehr als eine Soundkarte übermitteln und dabei die jeweilige monitord-Instanz instruieren.

Vorschlag:
Es gibt den bereits angesprochenen Launcher, der die monitord-Konfigurationsdatei auswertet und entsprechend viele monitord-Instanzen startet. Der Launcher besitzt einen TCP-Port über den er Steuerkommandos mit EINER Frondend-Anwendung (wie einem "Monitor Manager") abwickelt. Darüber erhält er @rec-Anweisungen, kann zur Laufzeit konfigurationsänderungen vornehmen oder ferngesteuert einzelne monitord-Instanzen starten und stoppen.
Jede monitord-Instanz steht für ein komplettes Sounddevice und damit für zwei Kanäle. Jede Instanz verfügt über einen eigenen TCP-Port, auf dem sie die Auswertungen an mehrere Frontends übermittelt.

Ich würde gerne direkt eine Windows und Linux Version in C++ entwickeln wollen.

Ich würde mir da nicht zu viel auf einmal vornehmen, sonst kommt am Ende erst mal gar nichts raus. Ich sehe erst einmal keinen Grund, das Backend auf Windows zu portieren. Und beim Frondend ist ohnehin alles möglich, denn es gilt nur, die Daten eines TCP-Listeners auszuwerten.

Ich würde daher folgende Vorgehensweise vorschlagen:

• 1. Code entwirren und modularisieren (Buebchen)
  2. Backend "monitord" und Launcher bauen (Buebchen)
  2a. TCP-Kommunikatiosnprotokoll für Daemon und Launcher festlegen, Struktur der Config-Dateien festlegen (Nepomuck, Buebchen)
  3. Ausführliche Tests des Backends (Nepomuck) und Debugging (Buebchen)
  4. Bestehenden Frontend-Code zu "Frondend-Classic" konvertieren (Buebchen)
  5. Neues MySQL-Frontend erstellen -- dazu müssten Perl-Skripte völlig ausreichen (?)
  6. Testing der Frondends (Nepomuck u.v.a.) Dokumentation von Frond&Backend, der Konfigurationsdateien und den TCP-Protokollen (Nepomuck)
  7. Release 2.0
  7a. Release Bosix 0.2 :-)
  8. Spinnof diverser Frontends (Windows, Mac, Java, was-auch-immer)
  9. Projekt "Monitor Manager" als Control-Applikation für ein oder mehrere monitor Server
  10. Entwicklung des @rec-Streamings für die Backend-Version 2.1

...

Andreas

[jhr-online]

@buebchen: Korrekt. :)
@nepomuck: Nicht zu schnell verteilen! Wir haben noch mehr Entwickler und auch noch eine Menge vor. Um das zusammen zu tragen, ist irgendeine Form von live-Gespräch sinnvoll. Ich schlage da Chat vor, weil es das einfachste ist und leicht zu protokollieren ist. Skype kommt mit mir nicht in die Tüte (proprietär), was nicht heißt, dass du nicht jeden anrufen darfst ;)

jhr

[nepomuck]

Nicht zu schnell verteilen! Wir haben noch mehr Entwickler

Ich wollte nur mal ein paar Basics verteilen, damit mal was vorwärts geht. Selbstverständlich sollen so viele mitarbeiten wie möglich.
Lass uns eine Liste der Projektteilnehmer zusammenstellen und dabei berücksichtigen, was wer tun kann und tun möchte.

und auch noch eine Menge vor.

Hier bitte Vorsicht: Lass uns nicht zu viel auf einmal in 2.0 planen, sonst geht das ganze irgendwann baden. Erst Pflicht, dann Kür -- und ich glaube wir sind uns in so weit einig, dass die saubere Trennung von Frond und Backend absolute Priorität hat -- wenn das steht, bleibe genug Zeit, "eine Menge" anderer Dinge dazuzuprogrammieren.

Um das zusammen zu tragen, ist irgendeine Form von live-Gespräch sinnvoll. Ich schlage da Chat vor, weil es das einfachste ist und leicht zu protokollieren ist.

Sehe ich ja ein.
Schlag einen Termin vor, ich kann morgen oder Fraitag sowohl tagsüber als auch mal abends oder spätabends -- immer voraus gesetzt, es brennt nicht :-)

Andreas

[Buebchen]

Chatten ginge im Grunde auch mal ausnahmsweise während der Arbeit. Sofern sich keiner wundert, daß ich mal für 20 Minuten abwesend wirke (weil dann ggf. ein Anruf reinkommt) - ich würde aber schon weiterhin mitlesen.

Ansonsten wäre mir ab 21:00 Uhr recht. Da ist die Change da, daß ich ein wenig Ruhe habe (Kinder im Bett :-) ).

[Buebchen]

Vorschlag:
Es gibt den bereits angesprochenen Launcher, der die monitord-Konfigurationsdatei auswertet und entsprechend viele monitord-Instanzen startet. Der Launcher besitzt einen TCP-Port über den er Steuerkommandos mit EINER Frondend-Anwendung (wie einem "Monitor Manager") abwickelt.

Ähh. Hast Du ne Zeitmaschine oder so ?

Ich würde mir da nicht zu viel auf einmal vornehmen, sonst kommt am Ende erst mal gar nichts raus. Ich sehe erst einmal keinen Grund, das Backend auf Windows zu portieren. Und beim Frondend ist ohnehin alles möglich, denn es gilt nur, die Daten eines TCP-Listeners auszuwerten.

Den Port zu Windows habe ich zu eigenen Zwecken schon vor ein paar Jahren gemacht. Sofern etwas von meine Modulen einfließt wäre es eher ein Backport :-)

Ich würde daher folgende Vorgehensweise vorschlagen:

• 1. Code entwirren und modularisieren (Buebchen)
  2. Backend "monitord" und Launcher bauen (Buebchen)
  2a. TCP-Kommunikatiosnprotokoll für Daemon und Launcher festlegen, Struktur der Config-Dateien festlegen (Nepomuck, Buebchen)
  3. Ausführliche Tests des Backends (Nepomuck) und Debugging (Buebchen)
  4. Bestehenden Frontend-Code zu "Frondend-Classic" konvertieren (Buebchen)
  5. Neues MySQL-Frontend erstellen -- dazu müssten Perl-Skripte völlig ausreichen (?)
  6. Testing der Frondends (Nepomuck u.v.a.) Dokumentation von Frond&Backend, der Konfigurationsdateien und den TCP-Protokollen (Nepomuck)
  7. Release 2.0
  7a. Release Bosix 0.2 :-)
  8. Spinnof diverser Frontends (Windows, Mac, Java, was-auch-immer)
  9. Projekt "Monitor Manager" als Control-Applikation für ein oder mehrere monitor Server
  10. Entwicklung des @rec-Streamings für die Backend-Version 2.1

...

Andreas

Grundsätzlich würde ich das nicht alleine schaffen können. Deswegen bin ich froh, daß es noch andere Entwickler gitb. Neben diesem Projekt habe ich noch ein Hardware-Projekt laufen (4fach Besprechungsstelle mit Headset-Möglichkeit und PC Fernsteuerung - µC gesteuert) und ausserdem noch meinen "Dauerbrenner" Einsatzunterstützungsprogramm - der läuft schon seit Jahren. Da kommt dann auch der Windows-Port her.

zu 4: Alles was das Frontend angeht ist ManuelW unser Mann (sofern er will). Ich könnte das zwar auch noch machen aber dann würde es wohl noch einige Zeit dauern, bis ich dazu komme...

zu 5: Ok, das habe ich nicht kapiert. Aber ich kann ja mal beschreiben, wie ich das für mich gelöst habe (bzw. meinen Lösungsansatz):
Ich habe einen Dienst, der die Telegramme auswertet und in eine MySQL-DB schreibt (monitord). Nun habe ich einen zweiten Dienst (Verarbeitungsserver) der alle "interessanten" Änderungen in der Datenbank erkennt und an die Clients, die sich per TCP verbunden haben meldet. Dies geschieht in der Form: "Änderungen FMS - Zeile 45000 ist neu, Einsatzmittel dazu hat den ID-Wert 5500". Nun kann jeder Client selbst entscheiden, ob ihn das interessiert und holt sich bei Bedarf den kompletten Datensatz aus der Datenbank.

Alles andere ist erstmal ok. Verteilung und Roadmap kommt dann sicherlich im IRC/TelCo/wo-auch-immer.

[Dove]

Den Port zu Windows habe ich zu eigenen Zwecken schon vor ein paar Jahren gemacht. Sofern etwas von meine Modulen einfließt wäre es eher ein Backport :-)

da möchte ich wxWidgets für C++ vorschlagen.
Damit entwickeln wir einen Sourcecode und kompilieren den unter win und unix ohne was dran geändert zu haben.

[nepomuck]

Ähh. Hast Du ne Zeitmaschine oder so ?

Nein, warum?

zu 5: Ok, das habe ich nicht kapiert. Aber ich kann ja mal beschreiben, wie ich das für mich gelöst habe (bzw. meinen Lösungsansatz):
Ich habe einen Dienst, der die Telegramme auswertet und in eine MySQL-DB schreibt

Ach so. Ich dachte, es würde genügen stumpf und uninterpretiert alles was vom Backend kommt erst einmal in eine DB zu schreiben und einem anderen Task das spätere auswerten zu überleassen.

Ich hatte nur die Idee, den MySQL-Teil als eigenes Modul vom bestehenden Frontend zu trennen, so das man den Monitor auch ohne MySQL betreiben kann.

Andreas

[Buebchen]

Nein, warum?

Weil Du geschrieben hast "es gibt ...". Da bin ich gerade mal ein wenig verwirrt. Gibt es einen Launcher für den monitord ?

Ach so. Ich dachte, es würde genügen stumpf und uninterpretiert alles was vom Backend kommt erst einmal in eine DB zu schreiben und einem anderen Task das spätere auswerten zu überleassen.

Ich hatte nur die Idee, den MySQL-Teil als eigenes Modul vom bestehenden Frontend zu trennen, so das man den Monitor auch ohne MySQL betreiben kann.

Die Trennung finde ich ok. Warum auch nicht. Man muss ja auch nicht in die SQL Datenbank schreiben. Für mich ist die Funktion wichtig. Ich will insbesondere FMS und Alarmierung dokumentiert wissen. Aber andere können bestimmt ohne leben.

@Dove: wxWidgets hatte ich mir mal angeschaut. Sah nicht schlecht aus. War mir zu dem Zeitpunkt aber zuviel Einarbeitung :-( Für das Backend zum Glück auch erstmal nicht erforderlich.

[Dove]

@Buebchen:
für das Backend ist das wirklich nicht erforderlich.
Für das Frondend sicherlich eine gute möglichkeit.

Muss man gucken wie man das realisiert oder was für andere Vorschläge noch kommen bzw welche, die hier schon vorgestellt wurden, anklang finden.

In wxWidgets bin ich grade drin :D

[nepomuck]

Man muss ja auch nicht in die SQL Datenbank schreiben. Für mich ist die Funktion wichtig. Ich will insbesondere FMS und Alarmierung dokumentiert wissen.

Mir ist das auch wichtig -- aber auf getrennten PCs. Auf dem eigentlichen Monitor-Rechner soll kein MySQL laufen, da dieser von CD startet (Bosix) und da würde eine aktive SQL-Datenbank nur stören.
Ich habe einen MySQL-Server im Netz und der soll die Daten erhalten.

Andreas

[Buebchen]

Mir ist das auch wichtig -- aber auf getrennten PCs. Auf dem eigentlichen Monitor-Rechner soll kein MySQL laufen, da dieser von CD startet (Bosix) und da würde eine aktive SQL-Datenbank nur stören.
Ich habe einen MySQL-Server im Netz und der soll die Daten erhalten.

Andreas

Habe ich auch so gemacht. MySQL läuft am besten auf oder "neben" dem Webserver, da diese intensiver Daten austauschen. Der monitord schickt im Vergleich dazu nur geringe Datenmengen.

Die Frage ist also eigentlich, ob der monitord direkt in die SQL-DB schreibt, oder aber ein angemeldeter Client (=Robot) das erledigt.

[funkwart]

Hallo Forum,

hier tut sich ja gewaltig etwas! Sehr gut, ich bin gespannt, was bei Euren Bemühungen herauskommt.
Leider kann ich nur wenig hier beisteuern, weil ich leider nur begrenzte Ahnung in den Bereichen Programmierung, Netzwerk, DB habe.
Trotzdem denke ich, dass es doch relativ egal ist, wo der MySQL Server läuft, auf dem die Daten gesammelt werden. Wenn man dem Backend angeben kann, unter welcher IP der MySQL-Server erreichbar ist, ist es doch schnurzpiepe, ob der auf 192.168.x.y oder 127.0.0.1 läuft. Der User muss halt nur, wenn er MySQL-Unterstützung auswählt, einen Server einrichten und die Adresse angeben.
Oder habe ich da was falsch verstanden?

Gruß,
Funkwart

PS: Als Tester stehe ich natürlich gerne zur Verfügung. ;-)