[Web-SIG] Pre-PEP: The WSGI Middleware Escape for Native Server APIs

[PJ Eby]

On Tue, Sep 30, 2014 at 3:40 AM, Roberto De Ioris <roberto at unbit.it> wrote:
> While i totally like your proposal, i fear it will not solve one of the
> biggest problems without another layer:

Of course.  An escape to a native API isn't much use without the
native APIs.  ;-)

> currently (and i speak as the uWSGI author, so i am the first guilty here)
> when you want to use non-WSGI features you generally call into server api
> (like the one exposed in the 'uwsgi' virtual module). This means each
> server has its api, and this result as middlewares and apps to be adapted
> to each one (if possible)

Actually, no.  The entire point of this escape is so that only *part*
of an app needs to be adapted, and not any of the middleware or
frameworks sitting on top.  With this proposal, only the portion of an
application that uses websockets would dynamically switch to invoking
your API.

That is, this proposal handles the case where somebody writes a huge
Django, Flask, Pyramid or even Zope application and suddenly realizes
they need websockets for a new feature, but that new feature *also*
needs access to a session and various application objects loaded by
their framework's routing system.  As long as their server has *some*
websocket API, they can then write an escape to access that API within
the structure of their existing framwork, which itself does not need
to be modified.


> My proposal is to push "mensa" but to standardize a series of api
> (websockets and push at least) on top of it so that frameworks and
> middlewares can use them without worrying about the lower stack.

The idea here is that the mensa protocol allows such APIs to be
developed and used *without* existing frameworks needing to adopt them
or interact with them directly.  An application developer uses mensa
to *bypass* the framework and middleware, for some portion of their
application where it is advantageous.

Certainly, having standard APIs to escape *to* is a good idea, but not
necessary in order for the mensa protocol to be immediately useful.
If, for example, you provided a wsgi.native_api_hook for uWSGI, then
people could *safely* use your websocket API from inside their
existing apps based on WSGI frameworks, without needing a separate
process or routing mount point that cannot access the other parts of
their application (e.g. sessions, authentication, routing, loading
objects, etc.)