Hello.
What do you think about the idea to have a server-independent API for web programming in Common Lisp, similar to the Java Servlet API, Ruby Rack, etc. ?
We may take the current hunchentoot API and use it for other servers.
For example, we may implement the same request, reply, *dispatch-table*, sessions, cookies functions as provided by hunchentoot for google app engine (with ABCL). Then web applications may be freely moved between the hunchentoot and the google app engine (for course, if they don't depend on other APIs, like google app engine persistence api).
Another option, is to use this API to embed ECL into apache or nginx, and write Common Lisp web applications for these servers. If the API will be based on hunchentoot, existing and new Common Lisp web applications will be easily moved between hunchentoot and these servers.
(Embedding ECL into apache is already possible with mod_ecl[1]. We will only need to adopt the mod_lisp API to the hunchentoot-like interface, to make Lisp applications portable. Nginx has embedded perl, therefore it has an API for external modules; if we embed ECL into nginx, we again only need to adopt the nginx-specific API to the standard hunchentoot-like form, and Lisp we applications will become portable between servers).
But the most interesting option was suggested by Andrey Moskvitin in his blog [2]: to implement the hunchentoot-like interface for the Mongrel2 web server. The advantage of this solution is that it will work for any Common Lisp implementation, but not for only one (ECL or ABCL) as in the previous options. BTW, Mongrel2 integration for Common Lisp already exists in the form of cl-mongrel2 [3], and the question is again only in adopting the APIs.
Even although porting the hunchentoot interface as is to Mongrel2 will not allow to fully untilize the Mongrel2 high concurrency asynchronous IO features, it seems like a good improvement in the Common Lisp ecosystem.
It is roughly clear what parts of the hunchentoot API should turned into cross-server API: request, reply, cookies, sessions, request dispatch and handling (partially, only the basic things), conditions and error handling, miscellaneous (partially). Other parts, like acceptors, taskmasters, logging are not the interface between web application and server but rather the web server startup and configuration API.
Writing an actual implementation for another web server will clarify the questionable points.
And Andrey Moskvitin has yesterday started implementing the hucnentoot interfece for Mongrel2, therefore we have chances to see it soon. The parts Andrey quickly extracted from the hunchentoot codebase for the web server independent API may be found here: https://github.com/archimag/cl-wsal.
As you may notice, small incompatibility exists: huncentoot-error become wsal-error. There is also a peace of code from chunga: know-words.lisp. Andrey told us he just took everything is needed to make the interface code compilable.
The question for hunchentoot developers and community: in case of successful implementation of the hunchentoot-like API on other web servers, do you think it is good for hunchentoot itself to split its API into two parts: abstract web server interface shared with other servers, and actual common lisp implemented web server providing this interface?
Interestingly, hunchentoot emerged from a library to talk to mod_lisp and other front-ends [4].
Today, when hunchentoot is highly adopted, it seems reasonable to pick out it's web programming API into a separate module, and share this API between hunchentoot and other front-end adapters, maybe other common lisp web servers, etc. And this will not add implementation complexity to the hunchentoot itself (which was the cause of the mod_lisp support removal in the 1.0 release).
What do you think?
1. mod_ecl - http://mod-ecl.sourceforge.net/index.htm 2. The blog post by Andrey Moskvitin (russian language) - http://archimag-dev.blogspot.com/2011/02/restas-mongrel2.html 3. cl-mongrel2 - https://github.com/vseloved/cl-mongrel2 4. http://www.weitz.de/hunchentoot/#history