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.Zitat von jhr-online
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
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?
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.
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.
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.
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 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
Zitieren