Re: Inviting feedback on my proposed "ASGI" spec
Andrew Godwin <[email protected]> Thu, 10 Mar 2016 15:56:00 -0800
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <CAFwN1urEhGtZeghOwTDi_ZntGr6SQA75d02nbPZ1UXY4FN=1uQ@mail.gmail.com> |
--===============8816884075639717673== Content-Type: multipart/alternative; boundary=001a113cf5ac9518c8052dba8fdb --001a113cf5ac9518c8052dba8fdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 10, 2016 at 2:07 PM, Robert Collins <[email protected]> wrote: > On 11 March 2016 at 10:34, Andrew Godwin <[email protected]> wrote: > >> > >> > >> 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; furt= her > >> 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, a= nd > > 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. > > Perhaps thats a particularly browser-centric view? There's nothing > that strongly associates TCP with Python's slant on 'async' for me - > interfaces on top of message passing can be sync or async - as in fact > the switch you've got demonstrates :). > > Other names? > > quick thoughts... > WSGP (web services gateway protocol) > MuPGI (multiple protocol gateway interface) Maybe, but this is specifically oriented as a web-based protocol - I'm not proposing to replace all network processing here - and in that context, "async" largely means "I can do things outside a normal request-response process". I guess it would take a lot for me to change the name at this point, as it's already so many places, but I do see your point. > > > > >> For consistency, why not a dict unicode -> List[bytes] > > > > I personally think this is worse than a list of tuples (which you can a= t > > least feed straight into dict()) - the only header that comes through a= s > > multiple, ever, is Set-Cookie, after all. > > I think you're wrong about that 'only header' statement. > > rfc 7230 3.2.2 permits multiple header fields with the same field name > for all field values defined as comma separated lists, and for > set-cookie. > > So you can't feed it straight into dict, unless you place a > requirement on the server to always fold together multiple header > fields with the same field name.... and clients to not use that > either. Oh, and special case Set-cookie. > I would indeed want to require servers to always fold headers together into a comma-separated list, as that's what the RFC says, and it then means applications only have to deal with one kind of multi-header! Set-cookie is the annoying thing here, though. That's why it's dict inbound and list of tuples outbound right now, and I just don't know if I want to make the inbound one a list of tuples too, given I do definitely want to force servers to concat headers together (unless I find any examples of that screwing things up) Andrew --001a113cf5ac9518c8052dba8fdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Thu, Mar 10, 2016 at 2:07 PM, Robert Collins <span dir=3D"ltr"><<= a href=3D"mailto:[email protected]" target=3D"_blank">robertc@rober= tcollins.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>= On 11 March 2016 at 10:34, Andrew Godwin <<a href=3D"mailto:andrew@aerac= ode.org" target=3D"_blank">[email protected]</a>> wrote:<br> >><br> >><br> >> I realise this may sound bikesheddy, but it would be really good t= o<br> >> not call it ASGI. From your docs "<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<b= r> >> choose what=E2=80=99s best for their current runtime environment; = further<br> >> improvements may provide extensions where cooperative versions of<= br> >> receive_many are provided."<br> >><br> >> I'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.<br> ><br> ><br> > Better names are welcome, but I quite like ASGI's similarity to WS= GI, and<br> > the fact it's pronounceable as a single word. The "Asynchrono= us" part covers<br> > the way the whole system operates; async is already an overloaded term= , and<br> > while there might be initial confusion, I think "async" also= has strong<br> > associations with the sort of problems ASGI solves (like websockets), = which<br> > I think is useful.<br> <br> </span>Perhaps thats a particularly browser-centric view? There's nothi= ng<br> that strongly associates TCP with Python's slant on 'async' for= me -<br> interfaces on top of message passing can be sync or async - as in fact<br> the switch you've got demonstrates :).<br> <br> Other names?<br> <br> quick thoughts...<br> WSGP (web services gateway protocol)<br> MuPGI (multiple protocol gateway interface)</blockquote><div><br></div><div= >Maybe, but this is specifically oriented as a web-based protocol - I'm= not proposing to replace all network processing here - and in that context= , "async" largely means "I can do things outside a normal re= quest-response process".</div><div><br></div><div>I guess it would tak= e a lot for me to change the name at this point, as it's already so man= y places, but I do see your point.</div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"><span><br> <br> <br> >>=C2=A0 For consistency, why not a dict unicode -> List[bytes]<br= > ><br> > I personally think this is worse than a list of tuples (which you can = at<br> > least feed straight into dict()) - the only header that comes through = as<br> > multiple, ever, is Set-Cookie, after all.<br> <br> </span>I think you're wrong about that 'only header' statement.= <br> <br> rfc 7230 3.2.2 permits multiple header fields with the same field name<br> for all field values defined as comma separated lists, and for<br> set-cookie.<br> <br> So=C2=A0 you can't feed it straight into dict, unless you place a<br> requirement on the server to always fold together multiple header<br> fields with the same field name.... and clients to not use that<br> either. Oh, and special case Set-cookie.<br></blockquote><div><br></div><di= v>I would indeed want to require servers to always fold headers together in= to a comma-separated list, as that's what the RFC says, and it then mea= ns applications only have to deal with one kind of multi-header!</div><div>= <br></div><div>Set-cookie is the annoying thing here, though. That's wh= y it's dict inbound and list of tuples outbound right now, and I just d= on't know if I want to make the inbound one a list of tuples too, given= I do definitely want to force servers to concat headers together (unless I= find any examples of that screwing things up)</div><div>=C2=A0</div><div>A= ndrew</div></div></div></div> --001a113cf5ac9518c8052dba8fdb-- --===============8816884075639717673== 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 --===============8816884075639717673==--