[Web-SIG] Inviting feedback on my proposed "ASGI" spec

[Andrew Godwin]

On Thu, Mar 10, 2016 at 2:07 PM, Robert Collins <robertc at robertcollins.net>
wrote:

> On 11 March 2016 at 10:34, Andrew Godwin <andrew at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160310/0b3a6024/attachment-0001.html>