HN Explorer

25 comments

[ 4.0 ms ] story [ 62.4 ms ] thread
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...

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

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

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?

msbarnett
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
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.

[deleted]
(comment deleted)
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.

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://www.reddit.com/r/perl/comments/h46mr/plackpsgi_ecosys...

* http://www.reddit.com/r/perl/comments/h6qqr/the_psgi_is_the_...

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.