3 ms·

# WSGI def app(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) yield 'Hello World\n' # Rack ap

by irahul 15y ago

# WSGI def app(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) yield 'Hello World\n' # Rack app = proc do |env| [ 200, {'Content-Type' => 'text/plain'}, "a" ] end WSGI is the Rack for Python. In fact, WSGI predates Rack, and Rack is WSGI inspired.

pyninja 15y ago
# Pump def app(request): return { "status": 200, "headers": {"content_type": "text/plain"}, "body": "Hello World"}
- irahul 15y ago
  You sure have put effort and the project looks good, but I am missing the purpose. If the problem it tries to solve is parsing environ to form response objects, or providing vanilla middlewares, that problem is very well solved by a wsgi library. Have you looked at werkzeug?
  - pyninja 15y ago
    Pump aims to replace WSGI entirely. That is, I believe it does a better job of what WSGI was intended to do. I understand your point that web developers don't necessarily work with WSGI on a day-to-day basis. But if you look at the Ruby web community, Rack middlewares are much more prevalent than WSGI middlewares. Application developers (as opposed to framework developers) often add functionality as a Rack middleware, so that it can be reused in different applications, even using different frameworks. Why isn't that happening with Python as much? In the Python world, instead of writing even simple middlewares to for basic functionality like https://github.com/adeel/pump/blob/master/pump/middleware/params.py https://github.com/adeel/pump/blob/master/pump/middleware/pa... or https://github.com/adeel/pump/blob/master/pump/middleware/cookies.py https://github.com/adeel/pump/blob/master/pump/middleware/co..., every framework ends up reimplementing it. I believe this is because the WSGI API is ugly and not as easy to understand as it could be (just look at the average WSGI middleware).
    - moreyes 15y ago
      It seems that what you ended up doing is, in fact, reimplementing things that were implemented zillions of times before. Am I wrong or the Pump middleware doesn't work for any WSGI app? If it had followed the WSGI middleware basic concept, you'd be closer to achieve the goal of reusable components across frameworks. "Pump aims to replace WSGI entirely." <- this is very ambitious. :)
bobbyi 15y ago
They are both predated by: public class App extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); response.getWriter().println("Hello world"); } }
- irahul 15y ago
  And that is predated by # hello.cgi print "Hello World\n"; I wasn't trying to claim WSGI is the first web server to application server interface. I was just showing Rack and WSGI are similar, and Rack was WSGI inspired.
- ianb 15y ago
  Yes, but IMHO servlets got it all wrong, and WSGI took very little from servlets (though for instance Webware, a pre-WSGI framework did use the servlet model). But it owes much to the superior CGI model; replace processes with function calls and structure the response lightly and you have WSGI.
  - carlhu 15y ago
    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?
    - irahul 15y ago
      > 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 code is given a request as a parameter to a function, and must return a response? cgi is not given a request parameter - the request parameters are passed in the environment. And cgi doesn't return a response object - whatever it writes to stdout constitutes the response. cgi had to cater to all sorts of implementation - assuming request/response objects wasn't a possibility. Servlets and cgi aren't fundamentally different, but I guess we can agree they are sufficiently different.
hetman 15y ago
Rack was based on WSGI, however the point is valid since Pump is using an API closer to Rack than WSGI. Indeed, the Pump website states: "No fancy start_response or environ here."

by irahul 15y ago

pyninja 15y ago

# Pump def app(request): return { "status": 200, "headers": {"content_type": "text/plain"}, "body": "Hello World"}

irahul 15y ago
You sure have put effort and the project looks good, but I am missing the purpose. If the problem it tries to solve is parsing environ to form response objects, or providing vanilla middlewares, that problem is very well solved by a wsgi library. Have you looked at werkzeug?
- pyninja 15y ago
  Pump aims to replace WSGI entirely. That is, I believe it does a better job of what WSGI was intended to do. I understand your point that web developers don't necessarily work with WSGI on a day-to-day basis. But if you look at the Ruby web community, Rack middlewares are much more prevalent than WSGI middlewares. Application developers (as opposed to framework developers) often add functionality as a Rack middleware, so that it can be reused in different applications, even using different frameworks. Why isn't that happening with Python as much? In the Python world, instead of writing even simple middlewares to for basic functionality like https://github.com/adeel/pump/blob/master/pump/middleware/params.py https://github.com/adeel/pump/blob/master/pump/middleware/pa... or https://github.com/adeel/pump/blob/master/pump/middleware/cookies.py https://github.com/adeel/pump/blob/master/pump/middleware/co..., every framework ends up reimplementing it. I believe this is because the WSGI API is ugly and not as easy to understand as it could be (just look at the average WSGI middleware).
  - moreyes 15y ago
    It seems that what you ended up doing is, in fact, reimplementing things that were implemented zillions of times before. Am I wrong or the Pump middleware doesn't work for any WSGI app? If it had followed the WSGI middleware basic concept, you'd be closer to achieve the goal of reusable components across frameworks. "Pump aims to replace WSGI entirely." <- this is very ambitious. :)

bobbyi 15y ago

They are both predated by: public class App extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/plain"); response.getWriter().println("Hello world"); } }

irahul 15y ago
And that is predated by # hello.cgi print "Hello World\n"; I wasn't trying to claim WSGI is the first web server to application server interface. I was just showing Rack and WSGI are similar, and Rack was WSGI inspired.
ianb 15y ago
Yes, but IMHO servlets got it all wrong, and WSGI took very little from servlets (though for instance Webware, a pre-WSGI framework did use the servlet model). But it owes much to the superior CGI model; replace processes with function calls and structure the response lightly and you have WSGI.
- carlhu 15y ago
  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?
  - irahul 15y ago
    > 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 code is given a request as a parameter to a function, and must return a response? cgi is not given a request parameter - the request parameters are passed in the environment. And cgi doesn't return a response object - whatever it writes to stdout constitutes the response. cgi had to cater to all sorts of implementation - assuming request/response objects wasn't a possibility. Servlets and cgi aren't fundamentally different, but I guess we can agree they are sufficiently different.

hetman 15y ago

Rack was based on WSGI, however the point is valid since Pump is using an API closer to Rack than WSGI. Indeed, the Pump website states: "No fancy start_response or environ here."