Re: Collating follow-up on the future of WSGI
Graham Dumpleton <[email protected]> Thu, 21 Jan 2016 09:37:19 +1100
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <[email protected]> |
--===============1715772034903562946== Content-Type: multipart/alternative; boundary="Apple-Mail=_AA9B6B18-6B1A-4A19-AF9F-EDCD6CAF0EFA" --Apple-Mail=_AA9B6B18-6B1A-4A19-AF9F-EDCD6CAF0EFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Jan 2016, at 9:27 AM, Benoit Chesneau <[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. 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. > 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? Since there is nothing in WSGI environ called wsgi.thread now I have no = idea what you are really suggesting here. Graham > 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=99t = 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=_AA9B6B18-6B1A-4A19-AF9F-EDCD6CAF0EFA 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""><br class=3D""><div><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]" 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"">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><br = class=3D""></div><div>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><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><br = class=3D""></div><div>Since there is nothing in WSGI environ called = wsgi.thread now I have no idea what you are really suggesting = here.</div><div><br class=3D""></div><div>Graham</div><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]" = 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><br class=3D""></body></html>= --Apple-Mail=_AA9B6B18-6B1A-4A19-AF9F-EDCD6CAF0EFA-- --===============1715772034903562946== 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 --===============1715772034903562946==--