On Wed, Mar 26, 2008 at 5:30 AM, mickolka <[EMAIL PROTECTED]> wrote: > > I have been thinking about a heresy the past week, that instead of > > improving WSGI maybe we should just leapfrog it to a WebOb-based chain > > of servers, applicaiions, and middleware. Then the protocol could > > just create the request/response once a the beginning of the chain and > > let the middleware/application modify it rather than each middleware > > having to reinvent the wheel and parse obscure environ keys. But > > that's too radical to just do in Pylons right now. > > > > That is exactly what is done in J2EE ServeltFilter, request/response > get created and passed to the chain of filters, Filters are mapped to > some URLs or Servlets (controllers in Pylons world). I think it worth > considering something similar with Pylons in the future.
The reason WSGI is as it is, is to depend solely on Python builtin types and minimize the number of dependencies. The counterargument is that the designers of WSGI did not anticipate how difficult it would be to write a middleware that's fully correct given situations like delayed headers and chunked output and the needs of asynchronous servers. The 'start_response' callback and 'write' method double or triple the complexity of middleware, which scares many developers away from writing it, and means that much of the middleware that exists is wrong in edge cases, either because the developer couldn't figure it out, or because they threw up their hands and refused to code the complicated, little-used part. Thus the motivation for WSGI 2 which is gaining steam. WSGI will have to change in Python 3 in any case, because the changing relationship of string to unicode will make it invalid. (WSGI assumes bytestrings can be used as 'str' strings unchanged, which is not true in Python 3.) Replacing WSGI with a WebOb-like system would make things much easier for server writers, application writers, and framework writers. But it means the Python community would have to agree on a standard request/response object, which some would see as too specific, or too onerous for extremely high-traffic light-footprint low-memory use cases. Also, WebOb itself depends on an environ dict as currently spec'd. If you eliminate the environ as its data source, what source will it use instead? -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
