
Clack: Common Lisp Web Application Env (ala WSGI, Rack, Plack, Ring, WSAPI, etc) - draegtun
http://clacklisp.org/
======
draegtun
For completeness here are some additional links for the "similar" _web
application environments_ provided by other languages listed in the post
title:

* WSGI (Python) - <http://wsgi.org/wsgi/>

* Rack (Ruby) - <http://rack.rubyforge.org/>

* Plack/PSGI (Perl) - <http://plackperl.org/>

* Ring (Clojure) - <https://github.com/mmcgrana/ring>

* WSAPI (Lua) - <http://keplerproject.github.com/wsapi/>

~~~
bscofield
Hack (Haskell) - [http://hackage.haskell.org/cgi-bin/hackage-
scripts/package/h...](http://hackage.haskell.org/cgi-bin/hackage-
scripts/package/hack-2009.4.20)

Paste (Python) - <http://pythonpaste.org/> *

* WSGI is a spec, Paste was the original (AFAIK) implementation. Interestingly, WSGI was itself inspired by the Servlet API.

~~~
gregwebs
Hack is certainly usable, although I would consider it deprecated in favor of
WAI (mostly for performance reasons): <http://www.yesodweb.com/book/wai>

------
zachbeane
I love seeing installation instructions made simple by Quicklisp.

~~~
jimwise
Yeah -- there was a great example of this yesterday, too:

<http://nklein.com/2011/06/quicklisp-win-weblocks/>

------
pjscott
It looks like this offers no way to stream chunks of a response -- you send
the whole thing as a list of strings, or tell it to send a file.

~~~
msbarnett
I believe that's normally implemented as middleware on top of Rack et al.

I assume it's expected that the same strategy would be used here.

~~~
pjscott
IIRC Rack and WSGI and Ring all let you return lazy sequences for the body,
allowing you to stream responses.

~~~
draegtun
PSGI/Plack also provides streaming responses by sending back a callback
instead of the usual [$code, $headers, $body] array(ref).

ref: [http://bulknews.typepad.com/blog/2009/10/psgiplack-
streaming...](http://bulknews.typepad.com/blog/2009/10/psgiplack-streaming-is-
now-complete.html)

------
sedachv
archimag (of RESTAS fame) wrote WSAL, which does something similar:
<https://github.com/archimag/cl-wsal>

------
zokier
Is there really need for every language to have its own web stack? Most do
work with FastCGI, but treat it as second class citizen (or so it seems as an
outside spectator). This is somewhat similar effect to that every language
seems to have its own package manager.

~~~
draegtun
Have a read of these to see some of the benefits with having this abstraction:

* [http://search.cpan.org/~miyagawa/PSGI-1.03/PSGI/FAQ.pod#Why_...](http://search.cpan.org/~miyagawa/PSGI-1.03/PSGI/FAQ.pod#Why_do_we_need_this%3F)

* [http://www.reddit.com/r/perl/comments/h46mr/plackpsgi_ecosys...](http://www.reddit.com/r/perl/comments/h46mr/plackpsgi_ecosystem/)

* [http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_...](http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_limit/)

~~~
zokier
I can understand why some newer, better protocol than CGI or even FastCGI
might be useful. But why there isn't a "FastCGI 2.0" which would have the
advantages that these language-specific middleware boast, but which would be
language-agnostic on the server side. At least from my point of view most
languages are not that much different that they'd couldn't fit in a common
interface.

------
ScottBurson
Hmm, there seems to be quite a bit less here than in, say, Weblocks. No widget
system, no form support, no AJAX support.

Anyone else here using Weblocks?

~~~
evangineer
You've missed the point here, think framework-agnostic web server interface
(like WSGI or Rack) rather than web framework (like Django or Rails).

The Weblocks developers could use Clack to interface to web servers like Nginx
or Apache rather than maintain their own web server interfaces.

~~~
evangineer
Caveman is an example of a minimal Common Lisp web framework built on top of
Clack.

<https://github.com/fukamachi/caveman/>

Same developer is building a much richer framework called Utopian on top of
Caveman. <https://github.com/fukamachi/utopian>

