monitord-activemq / Verbesserung der Software

[schakko]

Hallo allerseits!
Erst einmal dir Martin (mdi), und auch dir Christopher (cwh), ein großes Lob für die Arbeit an monitord.
Um mich kurz vorzustellen: Ich bin Haupt-Entwickler des SMS-Alarmierungssystems ZABOS (www.zabos.info) und komme aus der Java-/PHP-Ecke. C++ ist eher nicht so meins ;-)

Aus diversen Gründen (mehr Details dazu in meinem Blog unter http://wap.ecw.de/archives/1529) habe ich mich die letzten beiden Tage hingesetzt und ein Plugin für monitord geschrieben, mit dem alle eingehenden Nachrichten automatisch in eine von ActiveMQ bereitgestellte Queue/Topic publiziert werden.
Ihr findet die Sourcen zum Plugin unter http://github.com/schakko/monitord-activemq.

Während der Arbeit an dem Plugin sind mir einige Sachen aufgefallen:
* Ist geplant, dass monitord auf Github verschoben wird? Würde die Arbeit der einzelnen Personen einfacher machen. Außerdem würde damit auch ein funktionierender (und nicht vollgespammter ;-) ) Bugtracker und ein funktionierendes Wiki existieren.
* Das Aufräumen des Trunks wurde ja bereits angesprochen. Viele Dateien werden automatisch erzeugt und sollten ignoriert werden.
* Existiert ein Code-Style für monitord, d.h. Einrückung, zu jeder Klasse gehört ein Header-File etc.?
* Ist geplant, dass monitord mit Unittests gefüttert wird? Ich habe im Trunk dazu nichts gefunden und mir meine eigene Lösung mit CxxTest zusammengeschustert (siehe Github-Repo).

Soweit erst einmal - ich hoffe, ich habe nicht zu viel Werbung gemacht ;-)

P.S.: Freue mich auf eine interessante Antworten!

[mdi]

Moinmoin,

willkommen im Forum und bei der monitord-Entwicklung :)!

Vielen Dank für das Lob, das jedoch nicht nur uns beiden zuteil werden darf - dekarl, Buebchen und SirFS stehen im Log des SVN auch als (momentan eher inaktive) Entwickler drin, auch die ursprüngliche Version des monitor von M. Grohmann hat ihren wesentlichen Teil dazu bei getragen... mit denen möchte ich das Lob mal direkt teilen (und hoffe, ich hab keinen vergessen =)).

Die Gründe fand ich interessant zu lesen; überhaupt ist die ganze Sache ein schicker Ansatz. Zu Deinen Fragen gibts dann auch gleich von meiner Seite die Antworten, ohne die Meinung anderer vorweg nehmen zu wollen:

1) Github - nein, es ist keine Verschiebung angedacht. Wir arbeiten ja gut mit dem SVN, und auf Probleme sind wir dort auch noch nicht gestoßen. In Sachen Bugtracker und Wiki hast Du einen wunden Punkt gefunden; der Bugtracker wird von einem Nutzer des monitord kostenfrei bereit gestellt, das mit dem hohen Spam-Aufkommen ist allerdings mittlerweile tatsächlich zu einer echten Spaßbremse mutiert. Ein Wiki ist in meinen Augen aufgrund der Existenz dieses Forums nicht unbedingt notwendig; die wesentlichen Infos sind ja auch über die Webseite verfügbar. Es gab Überlegungen, mal zu SourceForge zu wechseln.
2) Trunk aufräumen - gern. Meinereiner ist dahingehend momentan nicht tief genug in der GNU-Autoconf-Sache drin. Wenn Du da helfen kannst, ist das sicher gern genommen - eine Koordination ist hier im Forum ja kein aufwändiges Ding :).
3) Code-Styles existieren nicht in einer koordinierten Form. Somit schreibt an sich jeder Entwickler in dem von ihm am ehesten genutzten und verstandenden Style. Der bisherige Code weist im Wesentlichen wenigstens beim Thema Einrückungen eine gewisse Verlässlichkeit auf. Die Headerfile-Geschichte ist nicht kontinuierlich durchgezogen worden.
4) Es existieren keine mir bekannten Unit-Tests. Dazu muss ich allerdings sagen, dass ich zum monitord ein wenig gekommen bin wie die Jungfrau zum Kinde *schmunzel*. Ich habe den ZVEI-Auswerter zusammen gecoded. Danach stockte die Entwicklung erstmal, und da sich kein echter Maintainer fand, habe ich diese Rolle gern übernommen. Koordinieren und Sourcen gegenlesen kann ich, auch habe ich versucht, tiefer in den Code einzusteigen - aus Zeitgründen bin ich allerdings noch immer nicht richtig durch, geschweige denn dass ich "mal eben" was neues bauen würde.

Alles in allem ist das Projekt meiner Ansicht nach gern offen für neues, neue Schnittstellen und Co., sowie Menschen, die sich ein wenig mit dem "Aussehen" von Code und Repository sowie der Entwicklung von Anwendungsmöglichkeiten und Frontends befassen möchten. Entsprechend finde ichs auch super, dass Du hier gleich mit einer Handvoll Sourcen "herein kommst" :).

Viele Grüße
Martin

[alex]

Hi,
ich finds ja schön, dass es mit monitord voran geht!

Habe deshalb heute angefangen für mein EinsatzMonitorSystem einen Client für monitord zu schreiben. Mein System läuft seit 2007 bei uns in der FW und seit ca 1 Jahr jetzt mit monitord statt FMS32pro. Bisher läuft auch alles problemlos, aber vor Allem freu ich mich auf den Audiorecorder, dass die Meldungen nicht ganz im Klartext übers LAN gehen und ein Login zumindest ein paar Leuten problemchen bereitet :)

Gruß
alex

[cwh]

Dazu kann nur wieder sagen: Das Audiorecording lief schon mal ganz gut.

Ich hab mit der Version vom 16.09.2009 ein Alarmierungssystem für unsere Feuerwehr am laufen, die Audio astrein aufnimmt. Leider klappt das mit den neueren Versionen erstmal nicht mehr.

Ich verwende Linux. Ich möchte nicht ausschließen, dass es unter Windows vielleicht Probleme gibt.

Linuxpakete dieser Version gibts hier: http://tinyurl.com/monitord2009

[mdi]

Moin,

stimmt, das lief schonmal recht gut. Nach Umstrukturierung der internen Abläufe wird eine Referenz auf das Vaterobjekt des monitord nicht mehr weiter gegeben. Damit kann ein Socket-Befehl nicht mehr direkt an das betroffene CSndPipe-Objekt weiter gegeben werden, sondern muss vermutlich am sinnvollsten die Kette über den GlobalDispatcher "rauf laufen".

Viele Grüße
Martin
PS: Linux-Pakete, cooool :)!