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.