krdc und OpenSLP's slptool funktionieren nun mit knot's OpenSLP-kompatiblen Library..
geschrieben um 00:04. (0 Kommentare, Direkter Link)

Ich bin mehr als glücklich mit den Knot Fortschritten heute. Die OpenSLP API Implementierung ist soweit fertig, muss allerdings noch getestet werden. Ausserdem habe das RFC 2608 Implementationsdokument fertig.
geschrieben um 01:12. (0 Kommentare, Direkter Link)

Die Serverseite von Knot ist nun soweit fertig. Die naechsten Schritte sind, eine Dokumentation der genauen Implementation in Hinsicht auf RFC 2608 zu erstellen und dann die OpenSLP API alias RFC 2614 zu implementieren.
geschrieben um 21:48. (0 Kommentare, Direkter Link)

Scriptsprachen
Hatte die letzten Tage wieder eine der Phasen, wo ich entschlossen war, Scriptsprachen wie Python zu benutzen, nur um reumütig wieder zu C++ zurückzukommen. Es gibt zwei Probleme bei Python, Ruby und Perl, mit denen ich nicht zurechtkomme:

1. Es gibt keine konsequente und durchgängige API-Dokumentation. Bei Qt und KDE kommt man sehr weit mit den Online-Dokumentationen, und bei Java ohnehin. Aber Scriptsprachen haben durchgängig schwache Online-Dokumentation, und dabei vor allem ein Problem: es geht aus den Prototypen der Funktionen niemals der benötigte Typ der Parameter hervor. Bei simplen Funktionen ist das kein Problem. Bei komplizierten Funktionen, die Objekte als Parameter bekommen, kann man nur raten. Wenn die Dokumentation dann wenigstens im Text die Typen erwähnen würde (was unpraktisch, da weniger schematisch wäre, aber zumindest eine Lösung ohne Raten), könnte ich damit leben. Aber wenn ich für jede Funktion mir den Source Code ansehen muss, ist jegliche Zeitersparniss der Scriptsprache dahin.


2. Es fehlt mir bei allen üblichen Kandidaten die Möglichkeit, einfach und ohne grössere Installation GUI Applikationen in Python oder Ruby zu schreiben (Perl mag ich nicht für GUIs). TK bietet keine Zeitgemässe Oberfläche, PyQT/PyKDE ist kompliziert zu installieren und kann keine Designer-UI-Files einlesen, GTK ist nicht akzeptabel, wxWindows fehlt das Qt Backend und ist auch nicht so toll. Solange es keine einfache Möglichkeit gibt, beliebige C++/C APIs anzusprechen, zB durch ein COM-ähnliches Modell, lohnt sich der Umstieg für mich einfach nicht, weil ich meine gewohnten, umfangreichen APIs nicht habe und mich wieder mit Kleinkram abgeben muss, der in C++ einfacher gelösst wird weil die APIs einem mehr Arbeit abnehmen. Ein Komponentenmodell wie The Hub steht weit oben auf meiner Wunschliste.

geschrieben um 23:04. (0 Kommentare, Direkter Link)

Bin natuerlich nicht so weit gekommen, wie ich vorhatte, nur SrvType funktioniert. Auch hatte ich nicht beruecksichtigt, dass die FindScopes und GetProperty Funktionen der C API noch auf dem Server implementiert werden muessen... aber dieses Wochenende.
geschrieben um 01:03. (0 Kommentare, Direkter Link)

Internet Radio

Auf #kde-devel kam heute wieder das Thema Internet Radio für JuK auf. Ich habe mich ein wenig umgehört und offenbar hat GStreamer nur über das gnomevfssrc Plugin Support für ShoutCast, und das auch eher eingeschränkt. Daher habe ich angefangen mir die HTTP/Shoutcast-Implementierung in XMMS anzusehen um abschätzen zu können, inwieweit sich dieser Code für ein GStreamer-Plugin benutzen lässt. Problem bei der Implementierung ist allerdings, dass diese Multithreading benutzt.

Die Frage, die ich mir dabei stelle, ist, warum überhaupt ShoutCast so weit verbreitet ist. Es ist ein relativ hässlich, die UDP-Variante (UDP wird benutzt für Meta-Daten) kommt in der XMMS-Implementierung durch keine Firewall/NAT und vor allem dürfte das Protokoll bei ausgelastetem Netz oder Server eine Menge Ärger bereiten. Für Shoutcast dagegen spricht, dass es sehr einfach zu implementieren ist.
Die offensichtliche Alternative ist RTP, ggf mit RTSP. Real und Quicktime benutzen es standardmässig, der Windows Media Player kann zumindest damit umgehen und benutzt ansonsten ein vergleichbares Protokoll. Dennoch wird RTP in der freien Software Welt weitgehend ignoriert. Zum Teil wird es daran liegen, dass RTP oft mit weniger freien Codecs benutzt wird und daher wenig Angebote mit einer RTSP/RTP Implementierung nutzbar sind. Dennoch könnten Icecast und Freenode Radio auch davon profitieren. Angenommen freie und zuverlässige Implementierungen wären verfügbar, würde es sich lohnen, auf die wesentlich komplexere Protokollfamilie um RTSP umzusteigen? Oder macht die durch die einfache Implementierung von ShoutCast mögliche Vielzahl an Clients die Nachteile wieder wett?

geschrieben um 00:27. (0 Kommentare, Direkter Link)

The Knot ist wieder ein grosses Stueck weitergekommen. SrvRqsts vom UA, quasi die Hauptfunktion in SLP, funktionieren nun auch vollstaendig (alle SA und DA Funktionen habe ich schon vor ein paar Wochen fertiggestellt). Wenn ich morgen noch ServiceType Requests und Attribute Requests fertig bekomme, ist der Server ein vollstaendiger UA, SA und DA. Dann brauche ich nur noch die Client APIs, und ich habe OpenSLP beim Funktionsumfang bereits uebertroffen...
geschrieben um 03:14. (0 Kommentare, Direkter Link)

Habe die ersten Aenderungen in der Desktop Sharing GUI committed. Ziel ist es, den Text in den Dialogen verstaendlicher und vor allem kuerzer hinzubekommen. Teil des Konzeptes sind vor allem WhatsThis-Links, die die Hilfetexte strukturieren und hoffentlich dafuer sorgen, dass sich der User die jeweiligen Texte nur dann durchlesen muss, wenn er sie auch braucht. Ausserdem habe ich ein wenig am neuen Konfigurationssystem fuer den Client weitergearbeitet...
geschrieben um 17:48. (0 Kommentare, Direkter Link)

Test ;)

geschrieben um 13:59. (0 Kommentare, Direkter Link)