Re: Inviting feedback on my proposed "ASGI" spec

--===============6558753917954792143==
Content-Type: multipart/alternative; boundary=001a113d469481049c052db895f2

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

>
>
>
> I realise this may sound bikesheddy, but it would be really good to
> not call it ASGI. From your docs "
> Despite the name of the proposal, ASGI does not specify or design to
> any specific in-process async solution, such as asyncio, twisted, or
> gevent. Instead, the receive_many function can be switched between
> nonblocking or synchronous. This approach allows applications to
> choose what=E2=80=99s best for their current runtime environment; further
> improvements may provide extensions where cooperative versions of
> receive_many are provided."
>
> I'm worried that folk will assume a parallel between ASGI and asyncio,
> but there appears to be none... which is only a problem due to the
> room for confusion.


Better names are welcome, but I quite like ASGI's similarity to WSGI, and
the fact it's pronounceable as a single word. The "Asynchronous" part
covers the way the whole system operates; async is already an overloaded
term, and while there might be initial confusion, I think "async" also has
strong associations with the sort of problems ASGI solves (like
websockets), which I think is useful.

>  For consistency, why not a dict unicode -> List[bytes]

I personally think this is worse than a list of tuples (which you can at
least feed straight into dict()) - the only header that comes through as
multiple, ever, is Set-Cookie, after all.

Andrew

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote 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;paddi=
ng-left:1ex"><span class=3D""><br>
<br>
</span>I realise this may sound bikesheddy, but it would be really good to<=
br>
not call it ASGI. From your docs &quot;<br>
Despite the name of the proposal, ASGI does not specify or design to<br>
any specific in-process async solution, such as asyncio, twisted, or<br>
gevent. Instead, the receive_many function can be switched between<br>
nonblocking or synchronous. This approach allows applications to<br>
choose what=E2=80=99s best for their current runtime environment; further<b=
r>
improvements may provide extensions where cooperative versions of<br>
receive_many are provided.&quot;<br>
<br>
I&#39;m worried that folk will assume a parallel between ASGI and asyncio,<=
br>
but there appears to be none... which is only a problem due to the<br>
room for confusion.</blockquote><div><br></div><div>Better names are welcom=
e, but I quite like ASGI&#39;s similarity to WSGI, and the fact it&#39;s pr=
onounceable as a single word. The &quot;Asynchronous&quot; part covers the =
way the whole system operates; async is already an overloaded term, and whi=
le there might be initial confusion, I think &quot;async&quot; also has str=
ong associations with the sort of problems ASGI solves (like websockets), w=
hich I think is useful.</div><div><br></div><div>&gt; =C2=A0For consistency=
, why not a dict unicode -&gt; List[bytes]<br></div><div><br></div><div>I p=
ersonally think this is worse than a list of tuples (which you can at least=
 feed straight into dict()) - the only header that comes through as multipl=
e, ever, is Set-Cookie, after all.</div><div><br></div><div>Andrew</div></d=
iv></div></div>

--001a113d469481049c052db895f2--

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

--===============6558753917954792143==--