Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Graham Dumpleton]

> On 4 Jan 2016, at 11:27 PM, Cory Benfield  wrote:
> 
> All,
> 
> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do 
> it at all?**
> 
> It’s a new year, and that means it’s time for another attempt to get WSGI 2.0 
> off the ground. Many of you may remember that we attempted to do this last 
> year with Rob Collins leading the charge, but unfortunately personal 
> commitments made it impossible for Rob to keep pushing that attempt forward.

Although you call this round 2, it isn’t really. Robert’s effort was not the 
first time someone has pushed a WSGI 2.0 variant. So this is more like being 
about round 5 or 6.

In part because of those repeated attempts by people to propose something and 
label it as WSGI 2.0, I am very cool on reusing the WSGI 2.0 moniker. You will 
find little or no mention of ‘WSGI 2.0’ as a label in:

https://github.com/python-web-sig/wsgi-ng 


That is probably somewhat due to my grumbling about the use of ‘WSGI 2.0’ back 
then.

Time has moved on and so the bad feelings and memories associated with the 
‘WSGI 2.0’ label due to early failed efforts have faded, but I would still 
suggest avoiding the label ‘WSGI 2.0’ if at all possible.

My general feeling is that if any proposed changes to the existing WSGI (PEP 
) specification cannot be technically implemented on all existing WSGI 
server/adapter implementations that any new specification should not still be 
called WSGI.

In other words, even if many of these implementations may not be used much any 
more, it must be able to work, without needing to mark things as optional, on 
CGI, FASTCGI, SCGI, mod_wsgi, gunicorn, uWSGI, Waitress, etc etc.

This is purely to avoid the confusion whereby implementations cannot or choose 
not to implement any new specification. The last thing any WSGI server author 
wants is having to deal with a constant stream of questions and bug reports 
about not supporting an updated specification where technically it was never 
going to be possible. We have some obligation not to inflict this on what are, 
in nearly all cases, volunteers in the Open Source world who work on these 
things in their spare time and who are not doing it as part of their paid 
employment.

> Since then, the need for a revision of WSGI has become even more apparent. 
> Casual discussion on the web has indicated that application developers are 
> uncomfortable with the limitations of WSGI. These limitations are providing 
> an incentive for both application developers and server developers to take an 
> end-run around WSGI in an attempt to get a framework that is more suitable 
> for the modern web. A great example of the result of WSGI’s deficiencies is 
> Andrew Godwin’s channels work[0] for Django, which represents a paradigm 
> shift in application development that takes it far away from what WSGI is 
> today.
> 
> For this reason, I think we need to try again to get WSGI 2.0 off the ground. 
> But I don’t believe we can do this without getting broad consensus from the 
> developer community that a revision to WSGI is needed, and without 
> understanding what developers need from a new revision of WSGI. This should 
> take into account the prior discussions we’d had on this thread: however, I’m 
> also going to actively solicit feedback from some of the more notable WSGI 
> implementers, to ensure that whatever comes out of this SIG is something that 
> they would actually use.
> 
> This WG already had a list of requirements, which are as follows:
> 
> - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all 
> on a single port).

Any support for implementing WebSockets should though be seen as a separate 
requirement to implementing HTTP/2.

A specific WSGI server implementation may be able to support HTTP/2, but not 
support WebSockets, or it could support WebSockets via HTTP/1.x already. In 
fact basic request/response functionality of HTTP/2 maps into the existing WSGI 
API specification and doesn’t really require any changes be made to the WSGI 
specification.

For example, mod_wsgi already supports HTTP/2 by virtue of the fact that the 
mod_h2 module in Apache exists. The existing internal APIs of Apache and how 
mod_wsgi uses those means that HTTP/2 bridges into the WSGI world with no code 
changes to mod_wsgi.

To support WebSockets is a much bigger problem and is not achievable with CGI, 
FASTCGI, SCGI.

It may be able to be supported within the Apache/mod_wsgi implementation, but 
the major re-architecting required in the mod_wsgi code, and the fact that it 
couldn’t be done by simply exposing a socket, but by requiring a new high level 
abstract API be developed which doesn’t expose the actual socket object, means 
you are really talking about a whole new API.

To me the WebSocket requirement and the need for a completely new API rules out 
ever doing this as part of an updated WSGI specification. 

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Andrew Godwin]

On Mon, Jan 4, 2016 at 6:22 PM, Robert Collins 
wrote:
>
> I think that WSGI got many things right - thats why so many things
> support it - but identifying which of its attributes is a factor for
> success, and which isn't is really hard: we're a decade on, more or
> less, and the ecosystem is a lot bigger. w.r.t. ASGI, it sounds like
> mongrel2 just in earlier days. Its a nifty way to build things, but I
> think its missing a fairly important thing: its not conceptually
> simple any more.
>

I appreciate that, though I would argue that the spec makes it seem
more complex than it actually is. You can write a ASGI application in
about 4 lines, in a way that I think is no worse than start_response and
environ in WSGI:

while True:
_, request = layer.receive_many("http.request", block=True)
response = {"content": "Hello World!", "status": 200}
layer.send(request['reply_channel'], response)

There's no reason ASGI couldn't have a WSGI-like layer specified on top for
HTTP requests so it looked more like current WSGI, but with slightly nicer
request and response objects. That is, in fact, mostly what the Django
Channels code does right now.

Mongrel2's design had some other issues, ZeroMQ being top of the list
(it's just not a good queuing system), as well as being way too stateful
and complex.
I could probably go on about the differences at length, but I'll refrain :)


>  - likewise on the application side: we need a Django person engaged
> with this - I reached out for one at the start of the last initiative
> but didn't manage to hook anyone, flask folk being interested would be
> good etc.
>

Hi, I am very interested, obviously.

Django _will probably have_ websocket support by next release, and it
almost certainly will run using ASGI internally; what's up for debate is
how it gets served, either via a WSGI shim, a WSGI-NG shim or native
support in a server.

I'm a big believer in going for implementation and iteration and polish
before jumping to a PEP, which is why I didn't bring ASGI anywhere near
that process yet. Once it's done, tested, implemented and we get it running
well at scale, then I think it would be ready. Django got a big pot of
funding from Mozilla just to get this process done, and several large sites
waiting to beta test things and report back how they work in the real world.

That said, I'm not stuck in some world where Django is the only Python web
framework; I would love to see the input of others. My ideal would be for a
new spec to renew the interest in writing more "raw" web apps in Python,
rather than people turning to other languages which have ostensibly better
WebSocket etc. support.


> On the asyncio / await etc side: I leave this up to the author.
> Thunking to WSGI from awaitable's would be tedious and thread-heavy I
> suspect. Obviously it can be done. AFAIK right now there is no mass
> move to asyncio from the server frameworks around: we're not going to
> solve the problems they have today with WSGI (e.g. the server-specific
> websockets requirements) by  making standardisation be predicated on
> moving something like Django to a new server core. I recall attempts
> to move other big frameworks around years ago now, taking a long long
> time I think the question of 'how can we enable interop of HTTP
> applications in asyncio' is best handled by a dedicated effort
> analogous to WSGI but in that programming model.
>

I agree that tying things to asyncio is a Bad Idea; any proposal should
certainly be more friendly to it, but requiring people to write fully
asynchronous code is a sure way to lose the simplicity of WSGI. We'd have
to do an incredible amount of work to Django to make it fully asynchronous
like that, to the point where it may never happen. What would probably
happen is just serving requests one at a time using thread pools or
something.

Andrew
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Robert Collins]

I should also say - thanks for picking this up. I may have been a tad
on the grumpy side on my prior mail - new years
paging-in-of-everything-after-a-break.

-Rob

On 5 January 2016 at 01:27, Cory Benfield  wrote:
> All,
>
> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do 
> it at all?**
>
> It’s a new year, and that means it’s time for another attempt to get WSGI 2.0 
> off the ground. Many of you may remember that we attempted to do this last 
> year with Rob Collins leading the charge, but unfortunately personal 
> commitments made it impossible for Rob to keep pushing that attempt forward.
>
> Since then, the need for a revision of WSGI has become even more apparent. 
> Casual discussion on the web has indicated that application developers are 
> uncomfortable with the limitations of WSGI. These limitations are providing 
> an incentive for both application developers and server developers to take an 
> end-run around WSGI in an attempt to get a framework that is more suitable 
> for the modern web. A great example of the result of WSGI’s deficiencies is 
> Andrew Godwin’s channels work[0] for Django, which represents a paradigm 
> shift in application development that takes it far away from what WSGI is 
> today.
>
> For this reason, I think we need to try again to get WSGI 2.0 off the ground. 
> But I don’t believe we can do this without getting broad consensus from the 
> developer community that a revision to WSGI is needed, and without 
> understanding what developers need from a new revision of WSGI. This should 
> take into account the prior discussions we’d had on this thread: however, I’m 
> also going to actively solicit feedback from some of the more notable WSGI 
> implementers, to ensure that whatever comes out of this SIG is something that 
> they would actually use.
>
> This WG already had a list of requirements, which are as follows:
>
> - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all 
> on a single port).
> - Support graceful degradation for applications that can use HTTP/2 but still 
> support HTTP/1.x requests.
> - Graceful incremental adoption path - no upgrade-all-components requirement 
> baked into the design.
> - Support Python 2.7 and 3.x (where x is not yet discussed)
> - Support the existing ecosystem of containers (such as mod_wsgi) with the 
> new API. We want a clean, fast and approachable API, and we want to ensure 
> that its no less friendly to work with than WSGI, for all that it will expose 
> much more functionality.
> - Apps need to be able to tell what protocol is in use, and what optional 
> features are available. For instance, HTTP/2 PUSH PROMISE is an optional 
> feature that can be disabled by clients. Websockets needs to expose a socket 
> like object, and so on.
> - Support websockets
> - Support HTTP/2
> - Support HTTP/1.x (which may be just 'point at PEP-’.)
> - Continue to support lightweight shims being built on top such as 
> https://github.com/Pylons/webob/blob/master/webob/request.py
>
> I believe that all of these requirements are up for grabs, and subject to 
> change and consensus discussion. In this thread, then, I’d like to hear from 
> people about these requirements and others. What do you believe WSGI 2.0 
> should do? Just as importantly, what do you believe it should not do? What 
> prior art should we take into account? Should we bother revising WSGI at all, 
> or should we let the wider application ecosystem pursue its own solutions à 
> la Django's channels? Should we simply adopt Andrew Godwin’s ASGI draft[1] on 
> which channels is based and call *that* WSGI 2.0?
>
> Right now I want this to be very open. I’d like people to come up with a 
> broad statement listing what they believe should and should not be present in 
> WSGI. This first stage of the work is very general: I just want to get a 
> feeling for what the community believes is important. Once we’re done with 
> that, if the consensus is that this work is worth pursuing, I’ll come up with 
> an initial draft that we can start making concrete changes to.
>
> In the short term, I’m going to keep this consultation open for **at least 
> two weeks**: that is, I will not start working on an initial draft PEP until 
> at least the **18th of January**. If you believe there are application or 
> server developers that should be involved in this discussion, please reach 
> out to them and point them to this list. I personally have CC’d some people 
> that I believe need to be involved in the discussion, but please reach out to 
> others as well.
>
> I’d really love to come to the end of 2016 with a solid direction for the 
> future of web programming in Python. I’m looking forward to working with you 
> all on achieving that.
>
> Thanks,
>
> Cory
>
>
> [0]: https://channels.readthedocs.org/en/latest/
> [1]: https://channels.readthedocs.org/en/latest/asgi.html



-- 
Robert Collins 

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Robert Collins]

So, as Graham said, I think calling it 2.0 is a bit of an issue -
HTTP/2.0 and WSGI 2.0 are not synonymous, given the diverse
requirements we have.



On 5 January 2016 at 01:27, Cory Benfield  wrote:
> All,
>
> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do 
> it at all?**
>
> It’s a new year, and that means it’s time for another attempt to get WSGI 2.0 
> off the ground. Many of you may remember that we attempted to do this last 
> year with Rob Collins leading the charge, but unfortunately personal 
> commitments made it impossible for Rob to keep pushing that attempt forward.
>
> Since then, the need for a revision of WSGI has become even more apparent. 
> Casual discussion on the web has indicated that application developers are 
> uncomfortable with the limitations of WSGI. These limitations are providing 
> an incentive for both application developers and server developers to take an 
> end-run around WSGI in an attempt to get a framework that is more suitable 
> for the modern web. A great example of the result of WSGI’s deficiencies is 
> Andrew Godwin’s channels work[0] for Django, which represents a paradigm 
> shift in application development that takes it far away from what WSGI is 
> today.
>
> For this reason, I think we need to try again to get WSGI 2.0 off the ground. 
> But I don’t believe we can do this without getting broad consensus from the 
> developer community that a revision to WSGI is needed, and without 
> understanding what developers need from a new revision of WSGI. This should 
> take into account the prior discussions we’d had on this thread: however, I’m 
> also going to actively solicit feedback from some of the more notable WSGI 
> implementers, to ensure that whatever comes out of this SIG is something that 
> they would actually use.
>
> This WG already had a list of requirements, which are as follows:
>
> - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all 
> on a single port).
> - Support graceful degradation for applications that can use HTTP/2 but still 
> support HTTP/1.x requests.
> - Graceful incremental adoption path - no upgrade-all-components requirement 
> baked into the design.
> - Support Python 2.7 and 3.x (where x is not yet discussed)
> - Support the existing ecosystem of containers (such as mod_wsgi) with the 
> new API. We want a clean, fast and approachable API, and we want to ensure 
> that its no less friendly to work with than WSGI, for all that it will expose 
> much more functionality.
> - Apps need to be able to tell what protocol is in use, and what optional 
> features are available. For instance, HTTP/2 PUSH PROMISE is an optional 
> feature that can be disabled by clients. Websockets needs to expose a socket 
> like object, and so on.
> - Support websockets
> - Support HTTP/2
> - Support HTTP/1.x (which may be just 'point at PEP-’.)
> - Continue to support lightweight shims being built on top such as 
> https://github.com/Pylons/webob/blob/master/webob/request.py
>
> I believe that all of these requirements are up for grabs, and subject to 
> change and consensus discussion. In this thread, then, I’d like to hear from 
> people about these requirements and others. What do you believe WSGI 2.0 
> should do? Just as importantly, what do you believe it should not do? What 
> prior art should we take into account? Should we bother revising WSGI at all, 
> or should we let the wider application ecosystem pursue its own solutions à 
> la Django's channels? Should we simply adopt Andrew Godwin’s ASGI draft[1] on 
> which channels is based and call *that* WSGI 2.0?
>
> Right now I want this to be very open. I’d like people to come up with a 
> broad statement listing what they believe should and should not be present in 
> WSGI. This first stage of the work is very general: I just want to get a 
> feeling for what the community believes is important. Once we’re done with 
> that, if the consensus is that this work is worth pursuing, I’ll come up with 
> an initial draft that we can start making concrete changes to.
>
> In the short term, I’m going to keep this consultation open for **at least 
> two weeks**: that is, I will not start working on an initial draft PEP until 
> at least the **18th of January**. If you believe there are application or 
> server developers that should be involved in this discussion, please reach 
> out to them and point them to this list. I personally have CC’d some people 
> that I believe need to be involved in the discussion, but please reach out to 
> others as well.
>
> I’d really love to come to the end of 2016 with a solid direction for the 
> future of web programming in Python. I’m looking forward to working with you 
> all on achieving that.

Whats the goal? The goal I had when I started was to enable a
portable-across-servers websockets + HTTP/2 capability in the Python
world. A PEP is one route to doing that. Just putting some code

[Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Cory Benfield]

All,

**TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do it 
at all?**

It’s a new year, and that means it’s time for another attempt to get WSGI 2.0 
off the ground. Many of you may remember that we attempted to do this last year 
with Rob Collins leading the charge, but unfortunately personal commitments 
made it impossible for Rob to keep pushing that attempt forward.

Since then, the need for a revision of WSGI has become even more apparent. 
Casual discussion on the web has indicated that application developers are 
uncomfortable with the limitations of WSGI. These limitations are providing an 
incentive for both application developers and server developers to take an 
end-run around WSGI in an attempt to get a framework that is more suitable for 
the modern web. A great example of the result of WSGI’s deficiencies is Andrew 
Godwin’s channels work[0] for Django, which represents a paradigm shift in 
application development that takes it far away from what WSGI is today.

For this reason, I think we need to try again to get WSGI 2.0 off the ground. 
But I don’t believe we can do this without getting broad consensus from the 
developer community that a revision to WSGI is needed, and without 
understanding what developers need from a new revision of WSGI. This should 
take into account the prior discussions we’d had on this thread: however, I’m 
also going to actively solicit feedback from some of the more notable WSGI 
implementers, to ensure that whatever comes out of this SIG is something that 
they would actually use.

This WG already had a list of requirements, which are as follows:

- Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all on 
a single port).
- Support graceful degradation for applications that can use HTTP/2 but still 
support HTTP/1.x requests.
- Graceful incremental adoption path - no upgrade-all-components requirement 
baked into the design.
- Support Python 2.7 and 3.x (where x is not yet discussed)
- Support the existing ecosystem of containers (such as mod_wsgi) with the new 
API. We want a clean, fast and approachable API, and we want to ensure that its 
no less friendly to work with than WSGI, for all that it will expose much more 
functionality.
- Apps need to be able to tell what protocol is in use, and what optional 
features are available. For instance, HTTP/2 PUSH PROMISE is an optional 
feature that can be disabled by clients. Websockets needs to expose a socket 
like object, and so on.
- Support websockets
- Support HTTP/2
- Support HTTP/1.x (which may be just 'point at PEP-’.)
- Continue to support lightweight shims being built on top such as 
https://github.com/Pylons/webob/blob/master/webob/request.py

I believe that all of these requirements are up for grabs, and subject to 
change and consensus discussion. In this thread, then, I’d like to hear from 
people about these requirements and others. What do you believe WSGI 2.0 should 
do? Just as importantly, what do you believe it should not do? What prior art 
should we take into account? Should we bother revising WSGI at all, or should 
we let the wider application ecosystem pursue its own solutions à la Django's 
channels? Should we simply adopt Andrew Godwin’s ASGI draft[1] on which 
channels is based and call *that* WSGI 2.0?

Right now I want this to be very open. I’d like people to come up with a broad 
statement listing what they believe should and should not be present in WSGI. 
This first stage of the work is very general: I just want to get a feeling for 
what the community believes is important. Once we’re done with that, if the 
consensus is that this work is worth pursuing, I’ll come up with an initial 
draft that we can start making concrete changes to.

In the short term, I’m going to keep this consultation open for **at least two 
weeks**: that is, I will not start working on an initial draft PEP until at 
least the **18th of January**. If you believe there are application or server 
developers that should be involved in this discussion, please reach out to them 
and point them to this list. I personally have CC’d some people that I believe 
need to be involved in the discussion, but please reach out to others as well.

I’d really love to come to the end of 2016 with a solid direction for the 
future of web programming in Python. I’m looking forward to working with you 
all on achieving that.

Thanks,

Cory


[0]: https://channels.readthedocs.org/en/latest/
[1]: https://channels.readthedocs.org/en/latest/asgi.html


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Cory Benfield]

> On 4 Jan 2016, at 14:48, Damjan Georgievski  wrote:
> 
>> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do 
>> it at all?**
> …
>> - Support websockets
>> - Support HTTP/2
> 
> What does HTTP/2 support mean? What features of HTTP/2 need to be
> exposed in the wsgi api?

(CC-ing the list)

The current WSGI API does not provide any consensus method for doing server 
push. Such a thing could absolutely be done as an extension to WSGI in its 
current form, and we should consider that.

More generally, HTTP/2 is a bit more generous with what can be done with a 
stream than is the case in HTTP/1.1. For example, a stream could in principle 
be kept open indefinitely and used as a bi-directional communications channel: 
WSGI in its current form does not make that easy to do.

Cory


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Armin Ronacher]

Hi,

On 04/01/2016 16:15, Cory Benfield wrote:

I don’t believe that will work.

Correct.  This cannot be done except for very simplistic servers.


Regards,
Armin
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Cory Benfield]

> On 4 Jan 2016, at 12:27, Cory Benfield  wrote:
> 
> All,
> 
> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do 
> it at all?**

Having set up the conversation, I also want to take part in it. So let me 
outline what I think we need from WSGI 2.

In my opinion, right now WSGI suffers from the following problems:

1. No out-of-the-box support for the concurrent programming techniques that are 
becoming extremely popular in the Python community and that should be 
encouraged.
2. No support for WebSockets, HTTP/2 server push, or any kind of generalised 
“extension” to the HTTP/1.1 request-response model.
3. A lack of an “escape hatch” that allows an application to take 
responsibility for a connection from the server, thereby ensuring that servers 
WSGI servers are the bottleneck for innovative and unusual programming 
techniques.
4. A confused bytes/unicode model that makes it mandatory to mix bytes and 
unicode in confusing ways at different parts of the stack.
5. A backward-looking design that favours applications doing in-memory 
buffering of responses over flushing response data to disk as it becomes 
available.

For this reason, my ideal WSGI 2.0 would be a relatively minor revision of PEP 
, focusing on addressing these core concerns. PEP  actually contains a 
great deal of what we already need, but either does not make it mandatory or 
fails to provide examples of how the tools can be used to solve the problem.

Problem (4) is easily resolved by coming to a consensus position on what fields 
should be byte strings, what ones should be unicode strings, and then very 
clearly setting out the rules for handling each side of that interaction.

I’d like to remove the `write` callable and instead **require** that the return 
value from the application callable be an iterable that produces the body. This 
should help encourage applications to use generators (or coroutines, as 
discussed later) to iteratively generate their output. This should help with 
problem (5) because it will allow us to propagate backpressure through a WSGI 
server to its application, based on how swiftly the server is able to flush 
data to the network.

Problem (2) is not actually entirely true: uWSGI has demonstrated that it’s 
entirely possible to extend WSGI to handle websockets, and such a model could 
presumably also be used for HTTP/2 server push. I’d like to take the approach 
of essentially creating ‘blessed’ extensions for websockets and HTTP/2 server 
push that tie in with the requirement for concurrency in problem (1). These 
will serve double duty, firstly ensuring that there’s a widely applicable 
general approach to supporting these features, while also providing a useful 
example of how WSGI 2 can be extended to support similar HTTP protocol 
extensions in future.

Fixing problem (3) seems useful to me, but I definitely need feedback from 
server implementers to see how they feel about becoming essentially dumb TCP 
proxies for applications in some scenarios.

Fixing problem (1) is the hardest, and for that reason I’ve reached out to a 
few Python concurrency experts. The best idea I have right now is based on 
trying to standardise on the ‘awaitable’ type and the ‘async for’ logic from 
PEP 492 to base WSGI 2 on asynchronous iterators. Essentially, the WSGI 2 
callable would return a PEP 493 asynchronous iterable.

I have some concerns about this approach, however. Firstly, I’m nervous about 
how well this works when called from C (e.g. for servers like uWSGI). Secondly, 
I want to make sure that it continues to function well with other event loop 
implementations (e.g. Twisted). For that reason, I’m open to alternative 
suggestions here. However, I do believe we need to support Python applications 
running concurrently in an event loop (e.g. asyncio-based or Twisted-based).

I have one further thing that I believe is important: I believe we need to 
support Python 2.7. It’s my sincere belief that if WSGI 2 is Python 3 only, we 
will struggle to get anyone to implement it: both servers and application 
frameworks will wait for people to take up Python 3 before implementing it, and 
users will not take up Python 3 until servers and application frameworks 
support WSGI 2.

What do people think of these goals?

Cory



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Damjan Georgievski]

>>> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we 
>>> do it at all?**
>> …
>>> - Support websockets
>>> - Support HTTP/2
>>
>> What does HTTP/2 support mean? What features of HTTP/2 need to be
>> exposed in the wsgi api?
>
> (CC-ing the list)
>
> The current WSGI API does not provide any consensus method for doing server 
> push. Such a thing could absolutely be done as an extension to WSGI in its 
> current form, and we should consider that.
>
> More generally, HTTP/2 is a bit more generous with what can be done with a 
> stream than is the case in HTTP/1.1. For example, a stream could in principle 
> be kept open indefinitely and used as a bi-directional communications 
> channel: WSGI in its current form does not make that easy to do.
>

So will a general solution for both HTTP/2 and Websockets be exposing
the underlaying socket as an 'wsgi.fd' environment variable?



-- 
damjan
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Armin Ronacher]

Hi,

I personally probably do not want to participate in this discussion much 
but I want to leave some thoughts in case someone finds them useful.


I personally think that fundamentally "concurrent programming" and just 
getting access to a socket is not something that fits into a generically 
deployable container specification which is what WSGI largely is.  WSGI 
was quite trivially specified as what happens from request to response 
and even in that area it already suffered from significant limitations 
in regards to where the specification did not consider what servers 
would do with it.


I do not want to go into detail too much but WSGI the spec never really 
concerned itself with the vast complexity that is HTTP in practice 
(chunked requests, transfer encodings, stream termination signalling etc.)


I heavily doubt that dragging concurrency into the spec will make it any 
less problematic for real world situations.


Why do we need concurrency on the spec level?  I honestly do not see the 
point because in practical terms we might just make a spec that then 
cannot really be deployed in practice just because nobody would want to. 
 Making a server that gracefully shuts down when things are purely 
request/response is already tricky enough, but finding a method to shut 
down a server with active stream connections is something that does not 
even have enough agreement between implementations yet (which also needs 
a lot of client support) that I don't think will fit into a specification.


I honestly do not think that you can have it both ways: a WSGI 
specification and a raw socket.  Maybe we reached the point where WSGI 
should just be deprecated and frameworks themselves will fill the gap. 
We would only specify a data exchange layer so that frameworks can 
interoperate in some way or another.



Regards,
Armin
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Cory Benfield]

> On 4 Jan 2016, at 14:56, Damjan Georgievski  wrote:
> 
 **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we 
 do it at all?**
>>> …
 - Support websockets
 - Support HTTP/2
>>> 
>>> What does HTTP/2 support mean? What features of HTTP/2 need to be
>>> exposed in the wsgi api?
>> 
>> (CC-ing the list)
>> 
>> The current WSGI API does not provide any consensus method for doing server 
>> push. Such a thing could absolutely be done as an extension to WSGI in its 
>> current form, and we should consider that.
>> 
>> More generally, HTTP/2 is a bit more generous with what can be done with a 
>> stream than is the case in HTTP/1.1. For example, a stream could in 
>> principle be kept open indefinitely and used as a bi-directional 
>> communications channel: WSGI in its current form does not make that easy to 
>> do.
>> 
> 
> So will a general solution for both HTTP/2 and Websockets be exposing
> the underlaying socket as an 'wsgi.fd' environment variable?

I don’t believe that will work.

Both HTTP/2 and Websockets have framing logic, and HTTP/2 also has a 
moderately-complex connection-level state machine that makes passing off the FD 
to an application a fraught endeavour. I suspect in both cases they will be 
best handled by having a extension protocol that allows the protocol-specific 
logic to function sensibly. In both cases, standard Python generators used as 
coroutines would be totally suitable, with concurrency being the only fly in 
the ointment to getting this right.

Cory


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Cory Benfield]

> On 4 Jan 2016, at 15:08, Armin Ronacher  wrote:
> 
> I honestly do not think that you can have it both ways: a WSGI specification 
> and a raw socket.  Maybe we reached the point where WSGI should just be 
> deprecated and frameworks themselves will fill the gap. We would only specify 
> a data exchange layer so that frameworks can interoperate in some way or 
> another.

This is one of the bits of feedback I expected we’d get, and it’s one we really 
do need to consider. It’s possible that the time for WSGI is coming to a close.

However, I’d like to try not to give up as a first step. =)

Your core question seems to be: “why do we need a spec that specifies 
concurrency?” I think this is reasonable. One way out might be to take the 
route of ASGI[0], which essentially uses a message broker to act as the 
interface between server and application. This lets applications handle their 
own concurrency without needing to co-ordinate with the server. From there the 
spec doesn’t need to handle concurrency, as the application and server are in 
separate processes.

However, if the application and server run together (as with WSGI today), I 
don’t think we can get out of needing to talk about concurrency, because *not* 
talking about it essentially forces the application to assume that each 
request/response cycle runs in a new process and that it cannot share memory or 
resources. That’s what we have at the moment, and using something like asyncio 
or Twisted in such an environment is very tricky and essentially requires that 
you run on top a server that also uses them (see Hendrix or Klein).

Let’s step back for a moment and consider the most simple case: one request, 
one response, both sent across WSGI as a complete entity. Could we not specify 
that the application callable has to return an object that is analogous to a 
future/promise/Deferred: essentially, an object that can be waited on until the 
response is ready. In that situation, a WSGI server could repeatedly call the 
application callable and then wait until any of the future/promise/Deferreds is 
ready, then send that data back in the response. This would allow the 
application to use its own concurrency model. Setting aside whether it’s a good 
model (it’s not), do you agree that it would work?

If it would, I think it’s reasonable to consider whether we can come up with a 
different, sufficiently-general approach to this problem, potentially based on 
that kind of approach.

Cory


[0]: https://channels.readthedocs.org/en/latest/asgi.html


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Armin Ronacher]

Hi,

On 04/01/2016 16:30, Cory Benfield wrote:

Your core question seems to be: “why do we need a spec that specifies
concurrency?” I think this is reasonable. One way out might be to
take the route of ASGI[0], which essentially uses a message broker to
act as the interface between server and application. This lets
applications handle their own concurrency without needing to
co-ordinate with the server. From there the spec doesn’t need to
handle concurrency, as the application and server are in separate
processes.
I think the *only* way to scale websockets is to use an RPC system to 
dispatch commands and to handle fan out somewhere centralized.  This for 
instance works really well with redis as a broker.  All larger 
deployments of websockets I have worked with so far involved a simple 
redis to websocket server that barely restarts and dispatches commands 
(and receives messages) via redis.


That's a simple an straightforward way that still keeps deployments work 
well because you never restart the actual connections unless you need to 
pull a cable or you have a bug in the websocket server.


That's why I'm personally also not really interested in this topic as 
for large scale deployments this is not really an issue and for toy 
applications I do not use websockets ;)



Regards,
Armin
___
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

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Andrew Godwin]

Thought I should weigh in on this, as I got mentioned by name in it. Sorry
about maybe not getting the threading right, I wasn't subscribed to the
list still it sprang from the grave this morning!

So, to quote the reply I just sent to Cory in django-developers:


I don't think ASGI would be a suitable replacement for WSGI in the current
form; in particular, I suspect it will have a performance disadvantage,
though I've not quantified yet.

That said, if Django Channels does become the primary method for
communication with web clients, the only thing we would want out of WSGI 2
would be something that could easily plug into ASGI - that is, something
that supports WebSockets, can handle simultaneous connections with many
clients in the same thread via cooperative multitasking or similar, and
allows raw access to sockets. Given those things, an ASGI HTTP/WebSocket
protocol server could simply be a WSGI 2 application, allowing much better
code reuse.


In particular, ASGI is never going to be low-level enough for people who
want to do crazy things; there's no access to input and output socket
streams, for starters. While I've tried to maintain some of the WSGI
familiarity, the whole thing is one step higher a level of abstraction, and
with that brings inflexibility and slight performance decreases that I
suspect people will get mad about if it becomes WSGI 2.

Now, I do think that the majority of web frameworks out there right now
could be ported to ASGI in no time at all; the asgiref package I'm working
on will ship with an ASGI-to-WSGI wrapper that just makes that work, as
long as the WSGI application doesn't try and be too clever with output

I don't want to express an opinion on if this means WSGI 2 is unnecessary
since I'm pretty biased; we need _some_ sort of standard that covers
WebSockets going forward, or we have the uwsgi problem where everyone
invents their own API for it.

My wishlist, though, is basically:

- WebSocket support
- Concurrent client handling support
- WebSockets and HTTP mixed-mode (i.e. on the same port and URLs)
- Fix the bytes/unicode issue that's all over the place in the current spec

These would all work super well in making ASGI itself pluggable into WSGI 2.

HTTP/2 features also need some place (like server push), and there's other
things cropping up like WebRTC that we might need to eventually support.
This is one of the reasons ASGI separates transport from protocol encoding;
I know people will invent new crazy web stuff in the next few years, and I
wanted a pattern that could extend to support most protocol types without
changing the abstraction completely.

Andrew
___
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