<<<< aktuelle Einträge

KDE 4.0
Zu den Sachen, die ich gerne für KDE 4.0 hätte, gehört die vor ein paar Monaten bereits angesprochene Sprachen-/Platformunabhängigkeit. Mike Hearn hat dazu ein paar ausführlichere Blog-Einträge geschrieben. Mit dem Fazit stimme ich allerdings nicht überein. GObject fehlt eine Menge Funktionalität, wie in meiner Advogato Antwort beschrieben. Bislang habe ich die Platformunabhängigkeit bei meinen neuen APIs nicht bedacht, aber es gibt da einige Probleme:

• Wenn eine sprachenunabhängige API eine akzeptable Performance aufweisen soll, ist es unvermeidbar, dass Basistypen wie Strings von allen Sprachen aus benutzt werden.


• Das hat drei mögliche Konsequenzen:
  
  1. Entweder müssen die APIs auf Qt und dessen Basistypen basieren,
  
  
  2. die platformunabhägige API darf nicht QString&Co benutzen, oder
  
  
  3. QString muss zumindest ein Interface implementieren, so dass man QString einfach konvertieren kann in einen generischeren Typen der jeweiligen Platform.
  
  
  
  


• Gegen Option 1 spricht, dass man sich mit QString etwa so beliebt bei der Gnome-Fraktion machen würde, wie sie mit GObject


• Zweites Problem mit Option 1 ist Qt's Lizenz. Viele werden um keinen Preis GPL Bibliotheken benutzen wollen


• Punkt 2 hat das Problem, dass alle KDE APIs komplett umgeschrieben werden müssten, damit sie den generischen Typ benutzen. Das Resultat hätte auch nicht sehr viel mit Qt Code zu tun


• Mit Punkt 3 ist nicht zu rechnen, weil Trolltech andere Sorgen haben wird


• Alternative zu den gemeinsamen Basistypen ist, tatsächlich primitivere Typen zu nehmen, so wie GObject das macht. Damit wären die APIs allerdings so langsam, dass sie nicht für alle Einsatzzwecke benutzbar wären. Was das Ganze zumindest für mich uninteressant machen würde.

Ich habe derzeit keinen wirklichen Lösungvorschlag, aber zumindest was zum nachdenken...

System Services
Ein weiteres Thema derzeit ist Seth Nickel's System Services Konzept, das die guten alten init Scripts ablösen soll. Im Prinzip halte ich es für keine dumme Idee, aber derzeit gibt es viel grundlegendere Probleme, die der Implementierung im Wege stehen: es gibt keine Bibliotheken für die meisten System-nahen Kommandozeilen-Programme. Befehle wie ifconfig oder route benutzen obskure und schlecht dokumentierte Funktionen wie ioctls(), sysctls() und das /proc Filesystem, um ihre Aufgabe zu erledigen. Und das noch platformunabhägig. cp hat recht komplizierte und schwer richtig zu bekommende Algorithmen, und dies wird noch schlimmer mit erweiterten Attributen und mit Reiser4's Metadaten. Solange diese Funktionen nicht in handlichen Libraries verfügbar sind ist das Ersetzen von init scripts nicht so einfach.

geschrieben um 20:21. (0 Kommentare, Direkter Link)