Re: Collating follow-up on the future of WSGI
Graham Dumpleton <[email protected]> Thu, 21 Jan 2016 17:24:25 +1100
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
--===============5491224460859771429==
Content-Type: multipart/alternative; boundary="Apple-Mail=_96862688-37EF-4880-B361-ECF7D627D8BD"
--Apple-Mail=_96862688-37EF-4880-B361-ECF7D627D8BD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
I am still confused as to why you keep talking as if you seemingly are =
trying to force extensions to the existing WSGI specification into the =
core WSGI specification when an alternative has already been cited.
Extensions and the process for describing them and getting them =
accepted, plus the appropriate WSGI environ prefix, as has been =
mentioned before, is what is covered by:
http://wsgi.readthedocs.org/en/latest/specifications.html =
<http://wsgi.readthedocs.org/en/latest/specifications.html>
Being an extension means it is entirely optional for a WSGI server to =
try and implement it, thus allowing WSGI servers/adapters that cannot =
implement something to skip them. They stand as separate documents and =
would never become part of the core WGSI PEP.
Is there an issue with doing extensions per the process, and in the WSGI =
environ namespace, that was outlined in that URL? You seem to be =
suggesting a completely new way of handling extensions and ignoring what =
was laid down before.
So no one is saying you can=E2=80=99t have extensions, and that separate =
process gives you all the scope you need to do it.
In drafting your specification just fit it reference to what is =
described in that URL, using =E2=80=98x-wsgiorg.=E2=80=99 prefix keys.
Graham
> On 21 Jan 2016, at 4:13 PM, Benoit Chesneau <[email protected]> =
wrote:
>=20
> I am not speaking about websockets. You could use it for SSE, or some =
apps could use the Upgrade header to upgrade from http to their own =
protocol etc... The only discussion i saw about websockets are about the =
addition of an async api or an external api. I am not describing that. I =
am speaking about providing a low level abstraction like wsgi.input but =
adding to it the support of output. (I was referring to =
wsgi.multithread...). This low level interface would allow anyone to =
provide its own implementation(server) or usage (application) still =
acting as a *gateway* .
>=20
> Also who are "we"? I am starting to think the discussion is already =
done and only obscure details like the content_length or headers =
encoding should be discussed. The RAW_SOCKET have been added on demand =
of the gunicorn users. Such thing also exist in things like cherrypy if =
I remember. A lot of code around have been created over it. So before =
deciding it's unworkable or whatever I strongly invite you to consider =
it as an addition to the environ. And since some servers need to pass =
the data differently I then suggest a Resource object on which you can =
read and write and eventually poll. This is not a websocket but more a =
proxy ressource to the client connexion. I will come back asap with a =
small spec.
>=20
> I also propose a second addition to the protocol that formalize the =
addition of extensions to the protocol by the servers if they want to. =
Having for example something like "`wsg.extensions` . Such addition =
would help anyone to experiment changes over the wsgi before making such =
changes in the specification by itself possibly.
>=20
> I think we have a good opportunity to extend the WSGI specification to =
allow the users to take over the new challenges on the web without =
forcing them to use a concurrency mode or skip completely the WSGI spec. =
The interest I see in WSGI is its simplicity and low level interface =
allowing users to build whatever they want over it. The different =
workers and their support of different concurrency models and framework =
in gunicorn let me think it is possible. Are the participants of this =
thread ready to discuss it?=20
>=20
> - beno=C3=AEt
>=20
> On Wed, 20 Jan 2016 at 23:37, Graham Dumpleton =
<[email protected] <mailto:[email protected]>> wrote:
>> On 21 Jan 2016, at 9:27 AM, Benoit Chesneau <[email protected] =
<mailto:[email protected]>> wrote:
>>=20
>> again. any server can do such implementation if we create a new =
Resource abstraction. This abstraction would expose a common api to read =
and write. The implementation would be specific to the server.
>=20
> If you mean not exposing the raw socket and having a separate high =
level API for implementing something like WebSocket this was already =
talked about. The suggestion was that it should not be a part of WSGI. =
Develop that API independently with no link to WSGI. The idea of =
upgrading from WSGI to a different API isn=E2=80=99t practical for =
various WSGI servers as it isn=E2=80=99t possible to unwind the state of =
the connection path created to get to point of handling the WSGI =
application. The better scenario is that the switch to an alternate =
WebSocket API is handled completely within the web server however it =
needs to handle it, when it needs to handle it, and not be reliant on =
going into a WSGI application which then says, oh, I actually need that =
to be WebSocket.
>=20
>> Now like we have wsgi.thread I would instead suggest to add a system =
of capability or extension like in smtp, imap, ... so the servers that =
implement a specific extension can legally published it. Would it work =
for you?
>=20
> Since there is nothing in WSGI environ called wsgi.thread now I have =
no idea what you are really suggesting here.
>=20
> Graham
>=20
>> benoit
>>=20
>> On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton =
<[email protected] <mailto:[email protected]>> wrote:
>>=20
>>> On 21 Jan 2016, at 2:48 AM, Benoit Chesneau <[email protected] =
<mailto:[email protected]>> wrote:
>>>=20
>>>=20
>>>=20
>>> On Wed, Jan 20, 2016 at 1:57 AM Robert Collins =
<[email protected] <mailto:[email protected]>> wrote:
>>> On 20 January 2016 at 12:04, Benoit Chesneau <[email protected] =
<mailto:[email protected]>> wrote:
>>>=20
>>> >
>>> > not at all. But I made the assumption that the wsgi server =
maintained a
>>> > thread directly or not where the python application is running .
>>> >
>>> > In any case there is some sort of wrapping done in the same =
thread/process
>>> > where the python application is running. And then nothing stop to =
give the
>>> > socket away to the application and tell to the server to stop to =
communicate
>>> > with it.
>>>=20
>>> What socket?
>>>=20
>>> Data could be being passed by shm, for instance.
>>>=20
>>> -Rob
>>>=20
>>>=20
>>> While shared memory would be quite a bad idea, then why not. I still =
don't see why having a way to upgrade the connection can't be done.
>>>=20
>>> Call it I/O resource or Socket, the issue is the same. At the end =
nothing stop the server to pass the control to the app. If we forget the =
socket (which is btw the simplest design) then the server could stop to =
control the I/O resource when the application ask it to do it. At some =
point either a garbage collection or a basic resource return/claim flow =
could be used to definitely free the resource.
>>>=20
>>> The thing behind that is that it would allow the WSGI spec to only =
focus on providing a strict gateway workflow without forcing the =
application to adopt a concurrency model aync or not.
>>=20
>> No one has said you cannot do it. because though it is only able to =
be implemented in a subset of WSGI servers/adapters, then it doesn=E2=80=99=
t seem appropriate that it be a part of the core WSGI specification.
>>=20
>> This is the role of a WSGI extension as found at:
>>=20
>> http://wsgi.readthedocs.org/en/latest/specifications.html =
<http://wsgi.readthedocs.org/en/latest/specifications.html>
>>=20
>> So go talk to the authors of uWSGI, and the other couple of packages =
available for trying to plug these into some of the pure Python based =
WSGI servers and come to an agreement between yourselves as to a =
standard way of doing it and the extension specification can be added to =
the wsgi.org <http://wsgi.org/> site.
>>=20
>> Graham
>>=20
--Apple-Mail=_96862688-37EF-4880-B361-ECF7D627D8BD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">I am still confused as to why you keep talking as if you =
seemingly are trying to force extensions to the existing WSGI =
specification into the core WSGI specification when an alternative has =
already been cited.<div class=3D""><br class=3D""></div><div =
class=3D"">Extensions and the process for describing them and getting =
them accepted, plus the appropriate WSGI environ prefix, as has been =
mentioned before, is what is covered by:</div><div class=3D""><br =
class=3D""></div><div class=3D""> <a =
href=3D"http://wsgi.readthedocs.org/en/latest/specifications.html" =
class=3D"">http://wsgi.readthedocs.org/en/latest/specifications.html</a></=
div><div class=3D""><br class=3D""></div><div class=3D"">Being an =
extension means it is entirely optional for a WSGI server to try and =
implement it, thus allowing WSGI servers/adapters that cannot implement =
something to skip them. They stand as separate documents and would never =
become part of the core WGSI PEP.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Is there an issue with doing extensions =
per the process, and in the WSGI environ namespace, that was outlined in =
that URL? You seem to be suggesting a completely new way of handling =
extensions and ignoring what was laid down before.</div><div =
class=3D""><br class=3D""></div><div class=3D"">So no one is saying you =
can=E2=80=99t have extensions, and that separate process gives you all =
the scope you need to do it.</div><div class=3D""><br =
class=3D""></div><div class=3D"">In drafting your specification just fit =
it reference to what is described in that URL, using =E2=80=98x-wsgiorg.=E2=
=80=99 prefix keys.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Graham<br class=3D""><div class=3D""><br =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
21 Jan 2016, at 4:13 PM, Benoit Chesneau <<a =
href=3D"mailto:[email protected]" class=3D"">[email protected]</a>>=
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
style=3D"white-space:pre-wrap" class=3D"">I am not speaking about =
websockets. You could use it for SSE, or some apps could use the =
Upgrade header to upgrade from http to their own protocol etc... The =
only discussion i saw about websockets are about the addition of an =
async api or an external api. I am not describing that. I am speaking =
about providing a low level abstraction like wsgi.input but adding to it =
the support of output. (I was referring to wsgi.multithread...). This =
low level interface would allow anyone to provide its own =
implementation(server) or usage (application) still acting as a =
*gateway* .<br class=3D""><br class=3D"">Also who are "we"? I am =
starting to think the discussion is already done and only obscure =
details like the content_length or headers encoding should be discussed. =
The RAW_SOCKET have been added on demand of the gunicorn users. Such =
thing also exist in things like cherrypy if I remember. A lot of code =
around have been created over it. So before deciding it's unworkable or =
whatever I strongly invite you to consider it as an addition to the =
environ. And since some servers need to pass the data differently I then =
suggest a Resource object on which you can read and write and eventually =
poll. This is not a websocket but more a proxy ressource to the client =
connexion. I will come back asap with a small spec.<br class=3D""><br =
class=3D"">I also propose a second addition to the protocol that =
formalize the addition of extensions to the protocol by the servers if =
they want to. Having for example something like "`wsg.extensions` . Such =
addition would help anyone to experiment changes over the wsgi before =
making such changes in the specification by itself possibly.<br =
class=3D""><br class=3D"">I think we have a good opportunity to extend =
the WSGI specification to allow the users to take over the new =
challenges on the web without forcing them to use a concurrency mode or =
skip completely the WSGI spec. The interest I see in WSGI is its =
simplicity and low level interface allowing users to build whatever they =
want over it. The different workers and their support of different =
concurrency models and framework in gunicorn let me think it is =
possible. Are the participants of this thread ready to discuss it? <br =
class=3D""><br class=3D"">- beno=C3=AEt</div><br class=3D""><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"">On Wed, 20 Jan 2016 at =
23:37, Graham Dumpleton <<a href=3D"mailto:[email protected]" =
class=3D"">[email protected]</a>> wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On 21 Jan 2016, at 9:27 AM, =
Benoit Chesneau <<a href=3D"mailto:[email protected]" =
target=3D"_blank" class=3D"">[email protected]</a>> wrote:</div><br =
class=3D""><div class=3D""><div style=3D"white-space:pre-wrap" =
class=3D"">again. any server can do such implementation if we create a =
new Resource abstraction. This abstraction would expose a common api to =
read and write. The implementation would be specific to the server.<br =
class=3D""></div></div></blockquote><div class=3D""><br =
class=3D""></div></div></div><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><div class=3D"">If you mean not exposing the =
raw socket and having a separate high level API for implementing =
something like WebSocket this was already talked about. The suggestion =
was that it should not be a part of WSGI. Develop that API independently =
with no link to WSGI. The idea of upgrading from WSGI to a different API =
isn=E2=80=99t practical for various WSGI servers as it isn=E2=80=99t =
possible to unwind the state of the connection path created to get to =
point of handling the WSGI application. The better scenario is that the =
switch to an alternate WebSocket API is handled completely within the =
web server however it needs to handle it, when it needs to handle it, =
and not be reliant on going into a WSGI application which then says, oh, =
I actually need that to be WebSocket.</div></div></div><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
style=3D"white-space:pre-wrap" class=3D"">Now like we have wsgi.thread I =
would instead suggest to add a system of capability or extension like =
in smtp, imap, ... so the servers that implement a specific extension =
can legally published it. Would it work for you?<br =
class=3D""></div></div></blockquote><div class=3D""><br =
class=3D""></div></div></div><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><div class=3D"">Since there is nothing in =
WSGI environ called wsgi.thread now I have no idea what you are really =
suggesting here.</div></div></div><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><div class=3D""><br class=3D""></div><div =
class=3D"">Graham</div></div></div><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div style=3D"white-space:pre-wrap" =
class=3D"">benoit</div><br class=3D""><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"">On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton =
<<a href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a>> wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><br class=3D""><div =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 21 =
Jan 2016, at 2:48 AM, Benoit Chesneau <<a =
href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a>> wrote:</div><br class=3D""><div =
class=3D""><div dir=3D"ltr" =
style=3D"font-family:Helvetica;font-size:16px;font-style:normal;font-varia=
nt:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-i=
ndent:0px;text-transform:none;white-space:normal;word-spacing:0px" =
class=3D""><br class=3D""><br class=3D""><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"">On Wed, Jan 20, 2016 at 1:57 AM Robert Collins =
<<a href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a>> wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">On 20 January 2016 at 12:04, Benoit =
Chesneau <<a href=3D"mailto:[email protected]" target=3D"_blank" =
class=3D"">[email protected]</a>> wrote:<br class=3D""><br =
class=3D"">><br class=3D"">> not at all. But I made the assumption =
that the wsgi server maintained a<br class=3D"">> thread directly or =
not where the python application is running .<br class=3D"">><br =
class=3D"">> In any case there is some sort of wrapping done in the =
same thread/process<br class=3D"">> where the python application is =
running. And then nothing stop to give the<br class=3D"">> socket =
away to the application and tell to the server to stop to communicate<br =
class=3D"">> with it.<br class=3D""><br class=3D"">What socket?<br =
class=3D""><br class=3D"">Data could be being passed by shm, for =
instance.<br class=3D""><br class=3D"">-Rob<br class=3D""><br =
class=3D""></blockquote><div class=3D""><br class=3D""></div><div =
class=3D"">While shared memory would be quite a bad idea, then why not. =
I still don't see why having a way to upgrade the connection can't be =
done.</div><div class=3D""><br class=3D""></div><div class=3D"">Call it =
I/O resource or Socket, the issue is the same. At the end nothing stop =
the server to pass the control to the app. If we forget the socket =
(which is btw the simplest design) then the server could stop to control =
the I/O resource when the application ask it to do it. At some point =
either a garbage collection or a basic resource return/claim flow could =
be used to definitely free the resource.<br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">The thing behind that is =
that it would allow the WSGI spec to only focus on providing a strict =
gateway workflow without forcing the application to adopt a concurrency =
model aync or not.</div></div></div></div></blockquote><br =
class=3D""></div></div><div style=3D"word-wrap:break-word" class=3D""><div=
class=3D"">No one has said you cannot do it. because though it is only =
able to be implemented in a subset of WSGI servers/adapters, then it =
doesn=E2=80=99t seem appropriate that it be a part of the core WSGI =
specification.</div><div class=3D""><br class=3D""></div><div =
class=3D"">This is the role of a WSGI extension as found at:</div><div =
class=3D""><br class=3D""></div><div class=3D""> <a =
href=3D"http://wsgi.readthedocs.org/en/latest/specifications.html" =
target=3D"_blank" =
class=3D"">http://wsgi.readthedocs.org/en/latest/specifications.html</a></=
div><div class=3D""><br class=3D""></div><div class=3D"">So go talk to =
the authors of uWSGI, and the other couple of packages available for =
trying to plug these into some of the pure Python based WSGI servers and =
come to an agreement between yourselves as to a standard way of doing it =
and the extension specification can be added to the <a =
href=3D"http://wsgi.org/" target=3D"_blank" =
class=3D"">wsgi.org</a> site.</div></div><div =
style=3D"word-wrap:break-word" class=3D""><div class=3D""><br =
class=3D""></div><div class=3D"">Graham</div><br =
class=3D""></div></blockquote></div>
</div></blockquote></div></div></blockquote></div>
</div></blockquote></div><br class=3D""></div></div></body></html>=
--Apple-Mail=_96862688-37EF-4880-B361-ECF7D627D8BD--
--===============5491224460859771429==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
--===============5491224460859771429==--