[Web-SIG] WSGI2: write callable?

[Robert Collins]

On 27 September 2014 07:58, PJ Eby <pje at telecommunity.com> wrote:
> On Thu, Sep 25, 2014 at 11:32 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
>> So I propose we drop the write callable, and include a queue based
>> implementation in the adapter for PEP-3333 code.
>
> If you're dropping write(), then you might as well drop
> start_response() altogether, and replace it with returning a (status,
> headers, body-iterator) tuple, as in wsgi_lite (
> https://github.com/pjeby/wsgi_lite ) or as found in other languages'
> versions of WSGI.  (start_response+write was only ever needed in order
> to support legacy apps, so other languages never bothered.)

Ahha! useful history. That would save a load of complexity on server
and middleware authors behalf.

HTTP/2 has moved status to a pseudo header and dropped the status
reason, so we could also phrase this as:
(headers, body-iterator)

Also, (filing an issue now) we also need to support Trailers, which
HTTP/2 has preserved. So we need a final header block facility as
well.

That structure would lead to
(headers, body-iterator, trailers-callback)

But perhaps it would be nicer to say:
iterator of headers_dict_or_body_bytes
With the first item yielded having to be headers (or error thrown),and
the last item yielded may be a dict to emit trailers.

So:
def app(environ):
    yield {':status': '200'}
    yield b'hello world'
    yield {'Foo': 'Bar'}

is an entirely valid, if trivial, app.

What do you think?

> wsgi_lite has a couple of other protocol extensions, namely the
> 'wsgi_lite.closing' environment key, flagging callables' supported
> WSGI version (for transparent interop), and the argument binding
> protocol, but for the most part these are orthogonal to the calling
> schema.  I would suggest, however, that the calling protocol be
> flagged in some way to allow easier interop.

We're bumping the WSGI version, will that serve as a sufficient flag?

The closing thing is nice - its basically unittest.TestCase.addCleanup
for WSGI, allowing apps to not have to write a deep nested finally.
Lets start a new thread about the design for that specifically. You
note that exception management isn't defined yet - perhaps we can
tackle that as a group?

-Rob

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