Freeze zum ersten Release

[Buebchen]

Hallo,
Wenn ich das bei Lame abkupfere, dann bekomm ich das hin.

Warum brauchst Du das? Finde ich nämlich ehrlichgesagt etwas ... äh ... improvisiert.

Warum man ggf. das mitgelieferter jthread nutzen sollte / können sollte ? Naja. Weil es unter Windows kein vorinstalliertes gibt ... :)

Ich denke die lame Quelltexte werde ich demnächst mal aus dem Repository rausnehmen und stattdessen den leeren Ordner als Platzhalter drin lassen. Damit sollte man die lizenzrechtlichen Probleme umgehen können.

Eigentlich beim Inquiry auch nicht sinnvoll, da der Audiorecorder ja an einem Kanal hängt. Demnach würde es nur in die Channel Info passen, was aber eine Protokollanpassung mit sich brächte.
Kurz gesagt: Die Pluginsausgabe beim Inquiry kann man einfach streichen.

Oder man ergänzt die Plugininfo noch mit dem verbundenen Kanal. Dann würde es wieder Sinn machen. Da bisher nur der Audiorekorder interessant ist kann man auch einfach nur eine Aufnahme versuchen. Wenn der monitord dann meckert ist kein audioplugin installiert.

Ich bin mir nicht sicher, ob im Moment noch jemand am Protokoll weiterarbeitet. Ein neuer Thread dazu würde Sinn machen, um für die nächste Version dann den unnützen oder überholten Kram loswerden zu können. Für 2.0 würde ich das erstmal so lassen. Höchstens in Pflicht- und Optionalparameter einteilen.

Ich finde übrigens auch das Kommando 110 überflüssig. Wann und wozu sollte der monitord sich nach dem Client erkundigen?

Das kann schon Sinn machen. Wenn der Client sich intern in einer Schleife verrennt würde er den TCP-Socket nicht automatisch schließen. Solche Clients kann man dann mit einer "echo"-Check ausfindig machen. Genutzt wird es im Moment nicht. Höchstens zum testen/debuggen mal. Da es kein besonders grosser Programmieraufwand ist kann man das m.E. erstmal drin lassen.

Ok, dick ist mein diff nur, weil ich auch noch die Einrückung korrigiert hab - das sollte ich weglassen. Aber xmllint und mein emacs sind sich über folgende Problemchen einig, die ich einfach mal fixen werde:

Die Korrektur ist bestimmt sinnvoll. Wobei ich bei einer config datei die man wohl eher nie mit einer DCD segnen oder auch mal transformieren will das nicht so dramatisch sehe :) Dennoch sollte man da natürlich auch versuchen sich an die Standards zu halten.

[/Quote]

Betrifft auch Anwender, da es nicht immer möglich ist, ein Configfile zwischen zwei Systemen auszutauschen, je nach dem, wo man den Kram hininstalliert hat. Die Beispielconfig funktioniert auch nur selten out of the box, bevor man nicht den Pfad angepasst hat. Auch die Notwendigkeit für Windows und Linux unterschiedliche sample-configs zu haben würde damit entfallen.

Und was einen Packager betrifft, betrifft auch den Anwender, denn was ich im Paket schon erledige, muß der Anwender nach der Installation nicht mehr machen.

Grüße,
Christopher

Die Pfade relativ anzugeben halte ich auch für sinnvoll. Ich könnte mir da z.B. auch einfach einen PluginOrdner Parameter vorstellen (Entweder absolut oder relativ zum aktuellen Verzeichnis). Zum Thema Endungen: Da würde ich einfach erst dem Dateinamen als solches Versuchen und dann unter win32 ein .dll ergänzen. Unter linux ein .so . Damit wäre das Ziel der Portabilität der config files in Deinem Sinne erreicht, oder ?

Ich merke, daß cwh das ganze unter linux anwendet. Somit sieht er es natürlich mehr die Bedürfnisse, die da vorherrschen. Meistens ist das deckungsgleich oder unabhängig zum win32 System. Sollte dem nicht so sein sollten wir immer versuchen - so wie bisher auch - eine Lösung zu finden, die auf beiden Systeme arbeitet. Ich nutze msys ja nicht, weil es so besonders komfortabel ist sondern um möglichst wenig Einzelanpassungen pro System machen zu müssen.

Zum thema libtool könnte ich inzwischen vermutlich Bücher schreiben. Nicht, weil ich sie verstanden habe sondern weil es einfach ständig was zu meckern hat. Wer Zeit hat kann ja mal versuchen das sox v14 mit dem plugins unter msys zu kompilieren. Und dann auch noch zu seinem Programm zu linken ...

Ich werde irgendwann nochmal Visual C installieren und dann da die dll erstellen. Alles andere ist furchtbar.

[cwh]

Hi,

Warum man ggf. das mitgelieferter jthread nutzen sollte / können sollte ? Naja. Weil es unter Windows kein vorinstalliertes gibt ... :)

Öhm, man bekommt die libs da nicht irgendwie als dlls hin?

Ich denke die lame Quelltexte werde ich demnächst mal aus dem Repository rausnehmen und stattdessen den leeren Ordner als Platzhalter drin lassen. Damit sollte man die lizenzrechtlichen Probleme umgehen können.

Die Probleme hat man eigentlich nur als Distributor. Damit verhindert man also nur, daß man mal auf einer Distri landet bzw. in meinem konkreten Fall, daß man es im openSUSE Buildservice bauen kann. Und letzteres ist zur Bereitstellung von Binärpaketen für die gängigen Distributionen eine sagenhafte Arbeitserleichterung.

Oder man ergänzt die Plugininfo noch mit dem verbundenen Kanal. Dann würde es wieder Sinn machen. Da bisher nur der Audiorekorder interessant ist kann man auch einfach nur eine Aufnahme versuchen. Wenn der monitord dann meckert ist kein audioplugin installiert.

So mach ich das bisher auch und damit komm ich auch zurecht. Allerdings wäre die Info schon besser in der Kanalinfo afgehoben, denke ich.

Die Korrektur ist bestimmt sinnvoll. Wobei ich bei einer config datei die man wohl eher nie mit einer DCD segnen oder auch mal transformieren will das nicht so dramatisch sehe :) Dennoch sollte man da natürlich auch versuchen sich an die Standards zu halten.

Ist schon behoben. Ich würde die Linux Beispielconfig übrigens auch noch gerne mit Unix statt DOS Lineendings ausstatten. Das gibt aber dann einen 100%-diff.

Die Pfade relativ anzugeben halte ich auch für sinnvoll. Ich könnte mir da z.B. auch einfach einen PluginOrdner Parameter vorstellen (Entweder absolut oder relativ zum aktuellen Verzeichnis). Zum Thema Endungen: Da würde ich einfach erst dem Dateinamen als solches Versuchen und dann unter win32 ein .dll ergänzen. Unter linux ein .so . Damit wäre das Ziel der Portabilität der config files in Deinem Sinne erreicht, oder ?

Ich würde Pfade und Endung mit Präprozessorkommandos zur compiletime festlegen. Configure weiß alles, was man dazu braucht, heißt: den libpath und die Plattform.

Wenn konfiguriert ist, dann sollte erst geguckt werden, ob das geladen werden kann, wenn fehlt, dann würde einfach wie folgt ein Filename zusammenstöpselt werden:

LIBPATH/libmplugin_PLUGINNAME.SUFFIX

Ich würde das mal versuchen einzubauen, wenn keiner was dagegen hat.

Ich merke, daß cwh das ganze unter linux anwendet. Somit sieht er es natürlich mehr die Bedürfnisse, die da vorherrschen. Meistens ist das deckungsgleich oder unabhängig zum win32 System. Sollte dem nicht so sein sollten wir immer versuchen - so wie bisher auch - eine Lösung zu finden, die auf beiden Systeme arbeitet. Ich nutze msys ja nicht, weil es so besonders komfortabel ist sondern um möglichst wenig Einzelanpassungen pro System machen zu müssen.

Zum thema libtool könnte ich inzwischen vermutlich Bücher schreiben. Nicht, weil ich sie verstanden habe sondern weil es einfach ständig was zu meckern hat. Wer Zeit hat kann ja mal versuchen das sox v14 mit dem plugins unter msys zu kompilieren. Und dann auch noch zu seinem Programm zu linken ...

Ich werde irgendwann nochmal Visual C installieren und dann da die dll erstellen. Alles andere ist furchtbar.

Ja, ich verwende monitord ausschließlich unter Linux, daher weiß ich auch nicht um die Fallstricke, die man hat, wenn man das ganze versucht unter Windows zu bauen. Gibt es sox etc. nicht evtl einfach fertig gebaut für mingw?

Unter Linux baut monitord inzwischen ja einfach und problemlos durch.

Grüße,
Christopher

[dekarl]

Tag,

für einen Prerelease sehe ich primär die Themen
* mp3/ogg
* QuellcodeLizenz
* Installationsanleitung
* Beispielclient (k.A. ob es schon irgendwo kleine Java Applets für FMS32/Crusader gibt, dann müsste man nichts eigenes schreiben) damit man nach dem entpacken "irgendwas" sieht

Das ganze würde ich als ersten Stand den man Paketieren / Verteilen kann ansehen.


Für unser erstes "richtiges" Release stelle ich mir jedoch etwas mehr vor, ich fasse mal ein wenig meine Gedanken zusammen:

* Netzprotokolle fixieren bzgl. Zeitzonen... intern nur UTC, nach außen vmtl. Lokale Zeit in fms32/crusader und UTC im Monitorprotokoll. Umwandlung dann nur zur Anzeige im Client
* man kann den monitor auch unter linux für windows bauen... einfach mal ./configure -host=mingw32 laufen lassen... Geht natürlich nicht mit MySQL :( (für SQLite muß ich das mal prüfen, ist ein Grund das ich das möchte)
* wegen mir brauchen wir gar kein .mp3 unterstützen, Ogg Vorbis erfüllt den gleichen Zweck ohne die daran hängenden rechtlichen Fallsticke (Manches Linux spielt per default kein mp3, Windows kein Vorbis. Aber das kann man ja mit dem cortado applet umgehen)
* ich sehe auch noch nicht wirklich den Zweck von Plugins. diese sind ja primär interessant um Funktionen komplett ins Programm rein/raus zu bekommen ohne neu zu kompilieren. Wir haben weder so viele Plugins wie z.B. der Apache Webserver noch das Problem das keiner unseren Quellcode sehen darf ;) Damit wäre das ganze Pluginconfig Thema auch vom Tisch
* die LUA Filterfunktion finde ich gut, dort sollte allerdings noch das eigentliche Ereignis verändert werden könnten. (z.B. per Skript die default Funkrufnamen als Text ans FMS dranhängen, etc.)
* es fehlt noch eine fest integrierte (also nicht optionale) Historie inkl. Statusspeicher (aktueller Status) mit Anbindung an alle drei Protokolle
* darauf aufbauend Unterdrückung redundanter Status und ggf. Generierung fehlender Status. ("gehen Sie über die 1 in die 3"... Piep "3 ohne 1"...) das ganze je nach Geschmack im LUA damit es jeder an seine Bedürfnisse anpassen kann.
* Steuerung der Aufnahme per LUA Filter auf der Eingangsseite (z.B. bei Alarmierung 120 Sekunden aufnehmen, bei FMS Status 15 nur 60 Sekunden)
* Clientbibliothek in Java mit Beispielclients 1) "Batch" z.B. für SMS Versand und 2) ein Applet als Einsatzdisplay

spätestens ab hier sehe ganz klar die 2.1 als Ziel ;)

* Die Eingangsseite würde ich gerne mal Anpassen so das man auch andere Datenquellen als Soundkarten nutzen kann. (z.B. FMS32/Crusader/POC32 Server, oder auch POCSAG-Modems)
* integrierter HTTP Server mit ereignisgesteuertem Client (Stufe 1, einfach ein Protokollfenster das ohne reload alles eingehende zeigt)
* Verlagerung der Stammdaten in den Server (ggf. mit Im-/Export für die üblichen fremden Clients) und Erweiterung des Webclient zur Konfiguration
* Erweiterung Webclient um Kartendarstellung (siehe Openlayers) inkl. der Infrastruktur in den Auswertern/Protokollen dazu

[Buebchen]

Tag,

für einen Prerelease sehe ich primär die Themen
* mp3/ogg
* QuellcodeLizenz
* Installationsanleitung
* Beispielclient (k.A. ob es schon irgendwo kleine Java Applets für FMS32/Crusader gibt, dann müsste man nichts eigenes schreiben) damit man nach dem entpacken "irgendwas" sieht

Das ganze würde ich als ersten Stand den man Paketieren / Verteilen kann ansehen.

Um diesen Stand geht es mir erstmal. Ob man beim monitord zur 2.0 schon nen Client braucht (es gibt ja AllFMS, FMS32Pro Demo und Crusader Demo) kann man sicherlich kontrovers betrachten. Wenn jemand einen hat/macht ist das umso besser.

Ich möchte einfach das Thema zur einem Stand bringen wo ein Client-Entwickler sicher sein kann, was der monitord bietet (oder auch nicht). Könnte ja durchaus sein, daß deswegen noch kein Client exisitiert: Viele warten auf den ersten Release.

mp3/ogg (ich würde das unter sox zusammenfassen) halte ich auch für die 2.0 sinnvoll. Wenn die dann soweit fertig ist. Von mir aus nennen wir diesen Stand auch erstmal einen Milestone, wenn 2.0 quasi der grosse Knaller werden soll :)