Yeah, I also wanted to write about that. There's a good talk on the topic: <meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://blip.tv/file/4706750">http://blip.tv/file/4706750</a><div><br>

</div><div><a href="http://blip.tv/file/4706750"></a>Cheers,</div><div>Vsevolod<br>
<br><br><div class="gmail_quote">On Mon, Feb 21, 2011 at 6:06 PM, Marko Kocić <span dir="ltr"><<a href="mailto:marko.kocic@gmail.com">marko.kocic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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