Show HN: Pump, a dead simple Pythonic abstraction of HTTP. • Hacker News Board

Re: Show HN: Pump, a dead simple Pythonic abstraction of HTTP.

#61

Post by sergeys » Wed, Jul 27, 2011, 10:05 PM UTC

sigil wrote: post #59

masklinn wrote: post #57

Earlier quoted context omitted.

> I like the idea of Pump, and am tired of frameworks protecting me from HTTP. if you don't like being "protected from http" why not write raw wsgi applications?

How is a gateway that reads, buffers, and parses HTTP headers into an environment object [1] before turning it over to your "raw wsgi application" not protecting it from HTTP? WSGI protects you from HTTP. CGI protects you from HTTP. mod_python and mod_perl protect you from HTTP. If you're unable to read and parse the complete HTTP request yourself -- perhaps incrementally, there's an idea -- you're protected from HTT…

"Libraries over frameworks. In Soviet Framework Russia, you don't call code...code call YOU." -- exactly! Very few people get this, which is a shame.

Re: Show HN: Pump, a dead simple Pythonic abstraction of HTTP.

#62

Post by est » Thu, Jul 28, 2011, 11:33 AM UTC

LeafStorm wrote: post #53

est wrote: post #49

I never understand the mentality of modern wsgi/cgi design. Passing parameters using environ? Why not directly as a python request object?

For consistency. If there was a request object, there would need to be some sort of standard implementation that there was always access to so that the object could be properly instantiated, instance tested, etc. By using a plain old dict, you ensure compatibility at the cost of attribute access. Also because WSGI is designed to be low-level, and if you want a request object you should really be using a library or fr…

But the old model sucks. If a process can handle more than one request, how does it change environ if there is only one process?

Re: Show HN: Pump, a dead simple Pythonic abstraction of HTTP.

#63

Post by ianb » Thu, Jul 28, 2011, 4:21 PM UTC

irahul wrote: post #56

carlhu wrote: post #42

Earlier quoted context omitted.

Ianb, may I inquire as to what is the difference you mean between servlets and cgi. A cgi written in perl for example, was essentially a perl servlet, I think. How is the CGI model fundamentally different from a servlet model, where your application code is given a request as a parameter to a function, and must return a response?

> How is the CGI model fundamentally different from a servlet model, Since both are web server to application server interfaces, they aren't fundamentally different - the difference is cgi was language independent and hence defined for the common minimum. cgi couldn't have been defined in request and response objects - it would have caused trouble for languages which doesn't have objects. > where your application cod…

To add/agree: I think the biggest difference is that CGI dealt in data, and did not have objects/APIs/etc. In many ways it would have been reasonable to skip even that, and pass an HTTP request in on stdin, and get an HTTP response on stdout, with just some minimal sanitizing promises; but I don't think I've ever seen that approach. Coincidence of history I suppose. Anyway, WSGI also carefully avoided any objects, only using standard data structures (dicts/hashes, strings, ints, ordered-associative-arrays, and iterable response). The result is a functional API without an opinions.