5 ms·

Clack: Common Lisp Web Application Env (ala WSGI, Rack, Plack, Ring, WSAPI, etc)

74 points by draegtun 15y ago

zachbeane 15y ago
I love seeing installation instructions made simple by Quicklisp.
- jimwise 15y ago
  Yeah -- there was a great example of this yesterday, too: http://nklein.com/2011/06/quicklisp-win-weblocks/ http://nklein.com/2011/06/quicklisp-win-weblocks/
draegtun 15y ago
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/ http://wsgi.org/wsgi/ * Rack (Ruby) - http://rack.rubyforge.org/ http://rack.rubyforge.org/ * Plack/PSGI (Perl) - http://plackperl.org/ http://plackperl.org/ * Ring (Clojure) - https://github.com/mmcgrana/ring https://github.com/mmcgrana/ring * WSAPI (Lua) - http://keplerproject.github.com/wsapi/ http://keplerproject.github.com/wsapi/
- ikilledkojack 15y ago
  Don't forget Jack (Javascript) - http://jackjs.org/ http://jackjs.org/
  - draegtun 15y ago
    Thank you for adding. Anymore anyone?
    - ikilledkojack 15y ago
      rRack/Rook (R) - https://github.com/jeffreyhorner/rRack https://github.com/jeffreyhorner/rRack
    - benatkin 15y ago
      http://senchalabs.github.com/connect/ http://senchalabs.github.com/connect/
- bscofield 15y ago
  Hack (Haskell) - http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hack-2009.4.20 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/h... Paste (Python) - http://pythonpaste.org/ http://pythonpaste.org/ * * WSGI is a spec, Paste was the original (AFAIK) implementation. Interestingly, WSGI was itself inspired by the Servlet API.
  - bscofield 15y ago
    I included code samples from several of these in a presentation I did a little while ago: http://www.slideshare.net/bscofield/great-developers-steal/21 http://www.slideshare.net/bscofield/great-developers-steal/2...
  - gregwebs 15y ago
    Hack is certainly usable, although I would consider it deprecated in favor of WAI (mostly for performance reasons): http://www.yesodweb.com/book/wai http://www.yesodweb.com/book/wai
sedachv 15y ago
archimag (of RESTAS fame) wrote WSAL, which does something similar: https://github.com/archimag/cl-wsal https://github.com/archimag/cl-wsal
ScottBurson 15y ago
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?
- msbarnett 15y ago
  Well, by analogy with Rack, WSGI, Ring, Plack, etc, widget systems and forms and AJAX are way outside the scope of the problem that Clack is trying to solve. All of these systems boil down to providing a simple convention for web applications to interface with web servers by implementing exactly one function that takes the environment and returns a triple of response code, content-type, and content. Everything else you describe would be built on top of this, not built into this.
- evangineer 15y ago
  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 15y ago
    Caveman is an example of a minimal Common Lisp web framework built on top of Clack. https://github.com/fukamachi/caveman/ https://github.com/fukamachi/caveman/ Same developer is building a much richer framework called Utopian on top of Caveman. https://github.com/fukamachi/utopian https://github.com/fukamachi/utopian
- deleted 15y ago
  [deleted]
- nunb 15y ago
  I use weblocks for small demos and private stuff, but at work it's all Clojure now.
  - 15y ago
pjscott 15y ago
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 15y ago
  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 15y ago
    IIRC Rack and WSGI and Ring all let you return lazy sequences for the body, allowing you to stream responses.
    - draegtun 15y ago
      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-is-now-complete.html http://bulknews.typepad.com/blog/2009/10/psgiplack-streaming...
zokier 15y ago
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 15y ago
  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_do_we_need_this%3F http://search.cpan.org/~miyagawa/PSGI-1.03/PSGI/FAQ.pod#Why_... * http://www.reddit.com/r/perl/comments/h46mr/plackpsgi_ecosystem/ http://www.reddit.com/r/perl/comments/h46mr/plackpsgi_ecosys... * http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_limit/ http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_...
  - zokier 15y ago
    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.

74 points by draegtun 15y ago

zachbeane 15y ago

I love seeing installation instructions made simple by Quicklisp.

jimwise 15y ago
Yeah -- there was a great example of this yesterday, too: http://nklein.com/2011/06/quicklisp-win-weblocks/ http://nklein.com/2011/06/quicklisp-win-weblocks/

draegtun 15y ago

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/ http://wsgi.org/wsgi/ * Rack (Ruby) - http://rack.rubyforge.org/ http://rack.rubyforge.org/ * Plack/PSGI (Perl) - http://plackperl.org/ http://plackperl.org/ * Ring (Clojure) - https://github.com/mmcgrana/ring https://github.com/mmcgrana/ring * WSAPI (Lua) - http://keplerproject.github.com/wsapi/ http://keplerproject.github.com/wsapi/

ikilledkojack 15y ago
Don't forget Jack (Javascript) - http://jackjs.org/ http://jackjs.org/
- draegtun 15y ago
  Thank you for adding. Anymore anyone?
  - ikilledkojack 15y ago
    rRack/Rook (R) - https://github.com/jeffreyhorner/rRack https://github.com/jeffreyhorner/rRack
  - benatkin 15y ago
    http://senchalabs.github.com/connect/ http://senchalabs.github.com/connect/
bscofield 15y ago
Hack (Haskell) - http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hack-2009.4.20 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/h... Paste (Python) - http://pythonpaste.org/ http://pythonpaste.org/ * * WSGI is a spec, Paste was the original (AFAIK) implementation. Interestingly, WSGI was itself inspired by the Servlet API.
- bscofield 15y ago
  I included code samples from several of these in a presentation I did a little while ago: http://www.slideshare.net/bscofield/great-developers-steal/21 http://www.slideshare.net/bscofield/great-developers-steal/2...
- gregwebs 15y ago
  Hack is certainly usable, although I would consider it deprecated in favor of WAI (mostly for performance reasons): http://www.yesodweb.com/book/wai http://www.yesodweb.com/book/wai

sedachv 15y ago

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

ScottBurson 15y ago

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?

msbarnett 15y ago
Well, by analogy with Rack, WSGI, Ring, Plack, etc, widget systems and forms and AJAX are way outside the scope of the problem that Clack is trying to solve. All of these systems boil down to providing a simple convention for web applications to interface with web servers by implementing exactly one function that takes the environment and returns a triple of response code, content-type, and content. Everything else you describe would be built on top of this, not built into this.
evangineer 15y ago
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 15y ago
  Caveman is an example of a minimal Common Lisp web framework built on top of Clack. https://github.com/fukamachi/caveman/ https://github.com/fukamachi/caveman/ Same developer is building a much richer framework called Utopian on top of Caveman. https://github.com/fukamachi/utopian https://github.com/fukamachi/utopian
deleted 15y ago
[deleted]
nunb 15y ago
I use weblocks for small demos and private stuff, but at work it's all Clojure now.
- 15y ago

pjscott 15y ago

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 15y ago
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 15y ago
  IIRC Rack and WSGI and Ring all let you return lazy sequences for the body, allowing you to stream responses.
  - draegtun 15y ago
    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-is-now-complete.html http://bulknews.typepad.com/blog/2009/10/psgiplack-streaming...

zokier 15y ago

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 15y ago
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_do_we_need_this%3F http://search.cpan.org/~miyagawa/PSGI-1.03/PSGI/FAQ.pod#Why_... * http://www.reddit.com/r/perl/comments/h46mr/plackpsgi_ecosystem/ http://www.reddit.com/r/perl/comments/h46mr/plackpsgi_ecosys... * http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_limit/ http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_...
- zokier 15y ago
  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.