[Web-SIG] WSGI and asyncio (tulip)?

[Robert Collins]

On 15 October 2014 11:58, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 15 Oct 2014 11:28:42 +1300
> Robert Collins
> <robertc at robertcollins.net> wrote:
>> On 15 October 2014 11:10, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>> > Each time a connection is accepted, protocol_factory is called without
>> > arguments(**) to create a Protocol, a bidirectional stream Transport is
>> > created to represent the network side of the connection, and the two
>> > are tied together by calling protocol.connection_made(transport)."""
>>
>> So where would headers etc be supplied to the protocol for reads (and
>> for outputs)? Since the transport isn't the raw socket, its the bodies
>> only.
>
> For reads, it could be provided on e.g.
> transport.get_extra_info('headers'). Or if you want a flat mapping API,
> transport.get_extra_info('http_content_type'), etc.
>
> As for out-bound headers, it's a good question. But I think it's ok for
> the transport to have HTTP-specific methods, so
> transport.write_header(name, value) could be ok too.

Ok so on balance I suspect that this is different enough to the needs
for a blocking API - even with generators in use - that we're better
off keeping them separate.

But, for all the variables, headers etc, we can write a single
definition of the semantics at play - e.g. see the REMOTE_ADDR one.

Would that make sense as separate specs, the way RFC2616 has split
into separate RFCs in in the 723x update ?

Or one big spec with sections, and when a pep-3156 based protocol/api
is put together just add a section?

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud