[Web-SIG] WSGI and asyncio (tulip)?

[Robert Collins]

On 15 October 2014 08:01, Sylvain Hellegouarch <sh at defuze.org> wrote:
>
>
> 2014-10-14 20:57 GMT+02:00 Justin Holmes <justin at justinholmes.com>:
>>
>> To me, asyncio already provides a de-facto standard API for
>> asynchronous backends and Tornado/Twisted provide a high level API on
>> top of it. I have to say, I don't precisely grasp what WSGI actually
>> wishes to bring to the table.
>>
>> I guess if we're really talking about this, the lowest common
>> denominator is a set of cognizable abstractions for HttpRequest and
>> HttpResponse, right?
>>
>
>
> That's my feeling as well. But, considering the sheer amount of content
> produced in other threads, I guess I'm missing the point somehow ;)

I've opened https://github.com/python-web-sig/wsgi-ng/issues/12 to
ensure we track this.

WSGI is intended to be a lowest common denominator; WSGI itself
describes why it didn't have a request object, and a response object
likewise.

I agree about the wasted CPU in middleware in principle, but if you
look closely at e.g. webob -
https://github.com/Pylons/webob/blob/master/webob/descriptors.py - the
Request object is just a shim onto the environ dict, it doesn't
actually copy the data around or even inspect many keys. Creating a
Request object there does 2 trivial checks and you're done. Not enough
to worry about in a pragmatic sense. As long as the WSGI protocol
continues to support such lightweight shims, I think we're fine.
Supporting such shims allows frameworks to have their own aesthetic
(e.g. CamelCase vs lower_case) methods, side effects and more.

That said, personally I'd be very open to defining some base classes
nowadays, but only if we have roaring support for that from the
authors of existing middleware and application frameworks.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud