[Web-SIG] WSGI for HTTP/2.0 ?

[Benoit Chesneau]

On Sat, Sep 20, 2014 at 3:22 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:

> On Sat, Sep 20, 2014 at 9:23 AM, Robert Collins
> <robertc at robertcollins.net> wrote:
> > Well, thats certainly a challenge :). Whats the governance model here?
> > Is a PEP appropriate, and if so - that gives us a BFDL or BFDL
> > PEP-delegate to decide between bikeshed issues; and if its not a
> > bikeshed issue then resolving it is actually necessary.
>
> Yes, I think a good way forward would be to have a small cabal write a
> PEP and then announce it here for further feedback and then
> pronouncement by a BDFL or -delegate. If you want to be lead/editor,
> that sounds great. It also seems like you should definitely involve
> Graham and give credence to his thoughts.
>
> I'd be excited about this and happy to give feedback a little later
> once you've got some initial draft, as someone who likes to implement
> his applications directly on top of WSGI for now (but I've also
> implemented a couple of WebSocket servers).
>
> Cheers,
>
> Dirkjan
>
>
Last time was more about everyone wanted to discuss about the changes with
its own requirement list.  Which is already conflicting. Discussing if it
should be done outside the media designed for it is already out of topic
imo. So I won't discuss about it further.

Instead I wonder what is the appropriate medium to collect requirements and
others stuffs about it. Wiki ? Anything else?

For  a start I see these different topics


1) HTTP 1.1 vs HTTP 2:

-  HTTP 1.1 and HTTP2 have quite the same high level syntax (methods, uri,
headers, ...) but the way the data is transported differs. (data are sent
by frames in HTTP 2).
- in HTTP 2, data can be encrypted and compressed.
- in HTTP2 data can pushed from the server to the clients. More data can be
sent to the client
- in HTTP2 streams are multiplexed We have the concept of data channels and
these are more like message passings. Multiplexing existed in HTTP 1.1 with
pipelines but is barely supported right now by WSGI servers.


The concept of data channels and the PUSH features will requires more
concurrency at the server level.

At the application, things doesn't change that much. Everything can appear
like before. The only change is the PUSH feature.


2) Websockets, SSE and other similar protocoles are completely
asynchronous.  All this part is not really handled by WSGI. The way it is
generally implemented right now is awkward. The server generally extend the
WSGI protocol so the application get the socket. Then a specific library
handle the rest.


I actually wonder if websockets or other asynchronous protocols should be
handled  by the new WSGI SPEC. Shouldn't we just standardize the way the
socket is given to another library?


Anyway I think we should collect all requirements at application and server
level and then start to confront the current WSGI spec to them. And
iterate. Thoughts? Any other topic?

- benoit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20140920/80671948/attachment-0001.html>