<<<< aktuelle Einträge

C Applikationen
Die Sammlung von Gründen, warum man keine C Applikationen ans Internet lassen sollte, geht weiter. Das Sicherheitloch des Tages hat OpenSSL und macht so ziemlich jeden SSL-fähigen Apache-Server mindestens für Denial-Of-Service Attacken anfällig, und vielleicht auch mehr. Wie üblich ein völlig unnöiger Fehler in der Speicherverwaltung...

Suse 9.0
Suse 9.0 würde diese Woche angekündigt und soll angeblich User Mode Linux unterstützen. Für mich wäre das ideal, weil ich so mehrere Instanzen von Knot auf einem Rechner laufen lassen könnte. Da Herry, mein P166 Hauptserver, seine neue Festplatte nicht mag und ich auf das bei EBay ersteigerte VIA Eden MoBo warten muss, werde ich mich wohl auch gleich zum 15. Oktober mit der Installation gedulden und bis dahin Knot ein wenig ruhen lassen.

KDE 4.0
Die Liste der APIs, die ich schreiben will, wird immer länger. Neben den bereits angesprochenen InputStream/OutputStreams und XmlReader/XmlWriter, gibt es noch eine Reihe weiterer Dinge die ich schon allein für Knot gerne hätte:

1. Ich habe die API fertig für eine Klasse KDE::IO::Console, die angenehmen Zugriff auf STDIN/STDOUT/STDERR ermöglicht. qDebug/kdDebug() gehen mir bei Komandozeilen-Applikationen wie knottool auf die Nerven
   
2. Ich bräuchte Input-/OutputStreams ähnlich QDataStream, die für das Lesen von Netzwerkdaten geschrieben wurden. Dass heisst, dass es ein paar mehr Sicherheitsmechanismen gibt (wie eine Begrenzung von String-Längen) und Unterstützung für diverse Dinge, die in binären Protokollen auftauchen, wie zB 24-bit und 48-bit Zahlen und verschiedene String-Formate. Ausserdem muss der Stream mit verschiedenen Endian-Konfigurationen klarkommen. Damit soll Knot's SLP Parser ersetzt werden.
   
3. Ich möchte einen Namespace KDE::Protocols, in den Protokollimplementationen kommen. Erster Kandidat wäre Knot's SLP Parser (KDE::Protocols::SLP), und zweiter HTTP
   
4. Ich spiele immer noch mit dem Gedanken, Knot's IPC Mechanismus durch D-Bus zu ersetzen. Dafür würde ich ich mit jenen Input/OutputStreams in KDE::Protocols::DBUS das D-Bus Protokoll implementieren (niemals werde ich für etwas so sicherheitsrelevantes die C Implementierung benutzen, siehe oben)
   
5. Einen vernüftiger Serialisierungsstream, der (ähnlich Java) auch komplexere Graphen von Objekten serialisieren kann, wäre schön, und notwendig für Punkt 6. Mit Hilfe meines SmartPtrs sollte das auch in C++ möglich sein.
   
6. Ich schiele immer relativ gierig auf Prevayler und ähnliche Systeme. Für meine erweiterten Knot-Pläne wäre das mehr als nützlich, zumal ich denke, dass man mit SmartPtr auch das Hauptproblem von Prevaler (den Speicherbedarf) recht einfach in den Griff bekommen könnte.
   
7. Was mich stört an C++ ist, dass man für jedes Programm immer noch die uralte int main(int argc, char** argv) Funktion implementieren muss. Sich das Ersparen zu können und für die Argumente eine QStringList zu bekommen, zusammen mit einfachen Zugriff auf Environment-Variablen und einer besseren Lösung f¨r POSIX-Signale, wäre hübsch. Aber gerade bei Signalen weiss ich derzeit nicht, wie eine solche Lösung aussehen könnte.
   

Nunja, mit einer Knot-Pause bis Mitte Oktober schaffe ich es vielleicht bis Punkt 3.

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