On Tue, Sep 30, 2014 at 5:03 AM, Sylvain Hellegouarch <s...@defuze.org> wrote: > Hi, > > 2014-09-30 1:19 GMT+02:00 PJ Eby <p...@telecommunity.com>: >> * Web servers can expose their native API to any WSGI application or >> framework > > It's kind of already the case with all the existing servers. They all > perform the stream reading and HTTP parsing in their own native way and then > adapt those to WSGI. > Basically, all existing Python HTTP servers do this already. For some > servers, you can even bypass the WSGI mapping altogether if you know you're > only stay in the framework native-land.
Right: for the most part, it's an all-or-nothing choice, at least for a given mount point within the server. Either it's a WSGI app or a native app. The point of the escape is that you can still use your WSGI framework, with all its routing, session handling, authentication, application object loading, etc., right up to the point where you need to do something advanced. The mensa protocol allows you to jump out of WSGI and back to the native API at that point. > Shouldn't we drop the middleware idea altogether? For the PEP's purposes, the definition of "middleware" includes web frameworks themselves. That is, it allows you to use a framework's features in tandem with native server APIs, without actually touching WSGI directly in application code. > Servers seem happy enough to expose HTTP through WSGI for convenience and > compatibility but, frameworks use native objects and workflow and forget > about WSGI altogether. I seldom see them expose the environ or > start_response at a high level. Those details are kept hidden to respect > (sometimes brokenly) the WSGI protocol. And the idea of this proposal is that as long as a framework exposes a *single* `use_native_api()` feature in some way (or exposes enough WSGI for a user to use the trick shown in the PEP), then the user can continue to ignore WSGI, but can *also* access low-level, non-WSGI APIs, to do things that are fundamentally incompatible with WSGI. (Also, as the PEP mentions, the escape protocol only requires that the framework allow access to the environ, and provide a way to set the status, headers, and content of the framework's eventual response. Any non-trivial framework provides *some* form of these latter three functions; it's only a question of whether the environ (or a copy of it) is available to get hold of the `wsgi.native_api_hooks`.) _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
