Yeah, I also wanted to write about that. There's a good talk on the topic: http://blip.tv/file/4706750
http://blip.tv/file/4706750Cheers, Vsevolod
On Mon, Feb 21, 2011 at 6:06 PM, Marko Kocić marko.kocic@gmail.com wrote:
Clojure community did a pretty good job at using ring [1] as *the* web development api.
The concept is quite simple, basically it is a series of transformations of request objects using "handlers" and "middlewares". That approach enables them to have quite a few of libraries [2] that can be mixed and matched between different ring and thirdparty web server implementations and frameworks.
[1] https://github.com/mmcgrana/ring [2] https://github.com/mmcgrana/ring/wiki/Libraries
Regards, Marko
On Sun, Feb 20, 2011 at 4:36 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
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?
- mod_ecl - http://mod-ecl.sourceforge.net/index.htm
- The blog post by Andrey Moskvitin (russian language) - http://archimag-dev.blogspot.com/2011/02/restas-mongrel2.html
- cl-mongrel2 - https://github.com/vseloved/cl-mongrel2
- http://www.weitz.de/hunchentoot/#history
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel