Re: Collating follow-up on the future of WSGI

--===============6731715950347452087==
Content-Type: multipart/alternative; boundary=001a11c3eebc1fb92b0529cb8060

--001a11c3eebc1fb92b0529cb8060
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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?

benoit

On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton <[email protected]>
wrote:

>
> On 21 Jan 2016, at 2:48 AM, Benoit Chesneau <[email protected]> wrote:
>
>
>
> On Wed, Jan 20, 2016 at 1:57 AM Robert Collins <[email protected]=
>
> wrote:
>
>> On 20 January 2016 at 12:04, Benoit Chesneau <[email protected]> wrote=
:
>>
>> >
>> > 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.
>>
>> What socket?
>>
>> Data could be being passed by shm, for instance.
>>
>> -Rob
>>
>>
> 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.
>
> 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 eith=
er
> a garbage collection or a basic resource return/claim flow could be used =
to
> definitely free the resource.
>
> 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.
>
>
> 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.
>
> This is the role of a WSGI extension as found at:
>
>     http://wsgi.readthedocs.org/en/latest/specifications.html
>
> 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 WSG=
I
> 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
>  site.
>
> Graham
>
>

--001a11c3eebc1fb92b0529cb8060
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div style=3D"white-space:pre-wrap">again. any server can do such implement=
ation if we create a new Resource abstraction. This abstraction would expos=
e a common api to read and write. The implementation would be specific to t=
he server.<br><br>Now like we have wsgi.thread I would instead suggest to a=
dd a system of capability or extension  like in smtp, imap, ... so the serv=
ers that implement a specific extension can legally published it. Would it =
work for you?<br><br>benoit</div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr">On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton &lt;<a href=3D"mailto:=
[email protected]">[email protected]</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br>=
<div><blockquote type=3D"cite"><div>On 21 Jan 2016, at 2:48 AM, Benoit Ches=
neau &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">bchesneau=
@gmail.com</a>&gt; wrote:</div><br><div><div dir=3D"ltr" style=3D"font-fami=
ly:Helvetica;font-size:16px;font-style:normal;font-variant:normal;font-weig=
ht:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px"><br><br><div class=3D"gmail_=
quote"><div dir=3D"ltr">On Wed, Jan 20, 2016 at 1:57 AM Robert Collins &lt;=
<a href=3D"mailto:[email protected]" target=3D"_blank">robertc@robe=
rtcollins.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=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 a=
t 12:04, Benoit Chesneau &lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</a>&gt; wrote:<br><br>&gt;<br>&gt; not at a=
ll. But I made the assumption that the wsgi server maintained a<br>&gt; thr=
ead directly or not where the python application is running .<br>&gt;<br>&g=
t; In any case there is some sort of wrapping done in the same thread/proce=
ss<br>&gt; where the python application is running. And then nothing stop t=
o give the<br>&gt; socket away to the application and tell to the server to=
 stop to communicate<br>&gt; with it.<br><br>What socket?<br><br>Data could=
 be being passed by shm, for instance.<br><br>-Rob<br><br></blockquote><div=
><br></div><div>While shared memory would be quite a bad idea, then why not=
. I still don&#39;t see why having a way to upgrade the connection can&#39;=
t be done.</div><div><br></div><div>Call it I/O resource or Socket, the iss=
ue is the same. At the end nothing stop the server to pass the control to t=
he 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 ret=
urn/claim flow could be used to definitely free the resource.<br></div><div=
><br></div><div>The thing behind that is that it would allow the WSGI spec =
to only focus on providing a strict gateway workflow without forcing the ap=
plication to adopt a concurrency model aync or not.</div></div></div></div>=
</blockquote><br></div></div><div style=3D"word-wrap:break-word"><div>No on=
e has said you cannot do it. because though it is only able to be implement=
ed in a subset of WSGI servers/adapters, then it doesn=E2=80=99t seem appro=
priate that it be a part of the core WSGI specification.</div><div><br></di=
v><div>This is the role of a WSGI extension as found at:</div><div><br></di=
v><div>=C2=A0 =C2=A0=C2=A0<a href=3D"http://wsgi.readthedocs.org/en/latest/=
specifications.html" target=3D"_blank">http://wsgi.readthedocs.org/en/lates=
t/specifications.html</a></div><div><br></div><div>So go talk to the author=
s of uWSGI, and the other couple of packages available for trying to plug t=
hese into some of the pure Python based WSGI servers and come to an agreeme=
nt between yourselves as to a standard way of doing it and the extension sp=
ecification can be added to the <a href=3D"http://wsgi.org" target=3D"_blan=
k">wsgi.org</a>=C2=A0site.</div></div><div style=3D"word-wrap:break-word"><=
div><br></div><div>Graham</div><br></div></blockquote></div>

--001a11c3eebc1fb92b0529cb8060--

--===============6731715950347452087==
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

--===============6731715950347452087==--