Dienstag, 17. März 2009

Serverarbeiten und Umzug zu Blogger

Bis heute bloggte ich stets mit selbst programmierten Blog-Engines. Meistens waren sie in Common Lisp geschrieben. Mal sehen, ob Blogger für mich auf Dauer die richtige Lösung ist.

Für Webentwicklung finde ich Common Lisp nach wie vor besonders gut geeignet. Mittlerweile gibt es eine Fülle von Bibliotheken, Frameworks, Server-Implementierungen und so vieles mehr; im Gegensatz zur Situation vor etwa 10 Jahren, wo noch vieles von Grund auf neu geschaffen werden musste.

AllegroServe und ACL-COMPAT

Ich erinnere mich daran, wie ich den Webserver AllegroServe - einem Projekt des Lisp-Anbieters Franz Inc. - nach LispWorks portierte. AllegroServe war zwar OpenSource, machte jedoch regen Gebrauch von AllegroCL-Spezifika. Multithreading, Sockets, Timeouts, Bivalente Streams - Es war klar, das dieser Code niemals dafür geschrieben worden war auf etwas anderem als AllegroCL zu laufen. Dennoch kam es anders: Chris Double veröffentlichte einen Corman Lisp Port von AllegroServe und motivierte mich damit es ebenfalls zu probieren. Der erste Port nach LispWorks war für mich anfangs nur als Spielerei gedacht, doch dann veröffentlichte ich das Ergebnis dennoch.

Das unerwartet große Interesse an einer Alternative zu CL-HTTP spornte mich an, aus dem Wochenend-Hack eine brauchbare Bibliothek zu schaffen. Mit ACL-COMPAT entwickelte ich eine Bibliothek, die gezielt zum Portieren von AllegroCL-Programmen gedacht war. Anfangs unterstützte ich nur LispWorks und CMUCL; doch es schlossen sich viele Helfer an: Chris Double, John DeSoi, Kevin Rosenberg, Vebjorn Ljosa, Edi Weitz, Peter Van Eynde und Rudi Schlatte. Helfer ist eigentlich bei weitem untertrieben und vielleicht sogar anmaßend - gerade Rudi Schlatte hat das Projekt noch lange Zeit weitergeführt, als ich schon längst nicht mehr ernsthaft beteiligt war. So unterstützt ACL-COMPAT und damit Portable AllegroServe heute GNU CLISP, CMUCL, Corman Lisp, LispWorks, MCL, OpenMCL, SBCL und SCL. ACL-COMPAT war nicht die erste CL-Bibliothek dieser Art, es war jedoch eventuell eine der ersten, die keine eigene API implementierte, sondern sich an einer bestehenden orientierte. Für mich war es der erste Erfolg eines gemeinschaftlichen OpenSource-Projekts.

Auf der Suche...

Eine ganze Weile war Portable AllegroServe meine Wahlplattform für Webanwendungen. Mit dem Webactions-Modell unzufrieden, begann ich bald damit ein eigenes Webframework zu entwickeln. (wie wahrscheinlich fast jeder andere Lisper ;-) )

Irgendwann erschien mir die AllegroServe-Basis als zu kompliziert für meine Zwecke. Wenn ich schon große Teile davon niemals verwende, würde es auch etwas einfacheres tun. Ich portierte mein Framework zu Daniel Barlows Araneida und schaltete gegebenfalls Apache mittels mod_proxy vor. Als Edi Weitz irgendwann mit Hunchentoot einen besonders für LispWorks optimierten Webserver veröffentlichte wechselte ich wieder. LispWorks war längst zu meiner Haupt-Entwicklungsplattform geworden und Hunchentoot war nicht nur schlank und übersichtlich, sondern lief einfach verdammt gut unter LispWorks.

Hunchentoot 1.0

Bis heute bin ich mit Hunchentoot sehr zufrieden. Ich hatte nie Probleme mit Abstürzen und der Quellcode ist überschaubar und gut lesbar. Ich betreibe Hunchentoot mittlerweile ohne vorgeschalteten Apache und bin mit der Performance sehr zufrieden. Demnächst steht das nächste Upgrade an. Version 1.0 wurde komplett überarbeitet: Die API ist eine offene Implementierung und bietet zahlreiche Möglichkeiten Hunchentoot zu erweitern. Die Performance soll noch einmal deutlich verbessert worden sein. In nicht mehr als einem Nachmittag konnte ich mein RESTful Webframeworks Ousion auf die neue Version portieren. In den kommenden Tagen wird Ousion und Hunchentoot 1.0 das momentane W3Broker+Hunchentoot-0.15.7-Gespann ablösen.