[hunchentoot-devel] web programming api for lisp

[Vsevolod Dyomkin]

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/4706750>Cheers,
Vsevolod


On Mon, Feb 21, 2011 at 6:06 PM, Marko Kocić <marko.kocic at 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 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
> >
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20110221/f107d159/attachment.html>