On Thu, Mar 10, 2016 at 2:07 PM, Robert Collins <robe...@robertcollins.net> wrote:
> On 11 March 2016 at 10:34, Andrew Godwin <and...@aeracode.org> 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’s 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. > > 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 at > > least feed straight into dict()) - the only header that comes through as > > 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
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
