[hunchentoot-devel] web programming api for lisp

[Marko Kocić]

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 at 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?
>
> 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
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>