[Web-SIG] WSGI2: write callable?

[PJ Eby]

On Sun, Sep 28, 2014 at 10:09 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> On 29 September 2014 08:32, PJ Eby <pje at telecommunity.com> wrote:
>>  On Sat, Sep 27, 2014 at 5:38 PM, Robert Collins
>> <robertc at robertcollins.net> wrote:
>>> I think we're uncovering important assumptions / facts here.
>>
>> Indeed!
>>
>>
>>> For clarity: I'm not interested in a nice API for HTTP/2. I want
>>> HTTP/2 and its full featureset to be *possible*, *efficient* and
>>> *clear* in a protocol that can replace WSGI - and do so with a fair
>>> chance of adoption.
>>
>> Cool.  Then my suggestion would be: don't use WSGI as a basis for
>> designing that protocol.  Start with something that's a natural fit
>> for the HTTP/2 model, which -- from what I can tell so far -- is
>> nothing like WSGI's simple request/response model.
>
> Thats a fair point. I have not been constrained by WSGI today in
> thinking about this - but since this effort is about updating the
> standard folk write to, for web server -> gateway -> app plumbing in
> Python, WSGI is, for better or worse, the touchstone folk have.
>
> WSGI's simple request/response model has been unable to fully handle
> the modern web since HTTP/1.1 came out (AFAIK none of the gateways
> have managed to make chunked uploads work right, and trailers are not
> supported). Thats not a bad thing about WSGI, and putting the union of
> requirements into a spec can make it unwieldy (see RFC2616 for a
> classic example :)) - but while we have a lot of frameworks that are
> a) composed of WSGI adapters and b) WSGI on the top, or WSGI on the
> bottom, they're not following WSGI all that precisely, because WSGI is
> too restrictive. And the web has moved on with Websockets in 2011 and
> HTTP/2 any day now.
>
> I think its clear from the broad interest we've got that folk are
> interested in a new spec.
>
> Whats in a name?
>
> We could call it something else. RSGI as you humourously suggest, or
> we can call it WSGI.
>
> I think WSGI is the right name, because I don't think we want to aim
> for a situation where folk writing new servers write both WSGI and
> $NEWTHING support

On the contrary, that is *precisely* what we want -- though only in
the short run.

Why?  Because there is not currently any body of implementation
experience with HTTP/2 APIs that can be drawn from to create a stable
specification.

To create a solid spec, one that doesn't lock prematurely into an API
that *seems* usable but actually isn't, it's necessary to have some
real API usage experience.

Which, if I have understood you correctly in this thread, is
essentially nonexistent.  So an API specification at this point would
be more like an API *speculation*.  Ideas about what APIs might or
might not be useful or attractive.

So, rather than filling in $NEWTHING with a specific value, we want
$NEWTHING to be a *wildcard*, consisting of whatever HTTP/2 APIs you
and others can dream up -- or have already implemented.

One of two things will then happen: either one particular $NEWTHING
catches on to the point of being a clear winner (and therefore basis
for a standard), *or* it will then be possible to deduce a
common-denominator low-level protocol common to the various
$NEWTHINGs, which will then become the official New Thing.  Either
way, de facto beats de jure, where standards are concerned.


> So - I'm going to keep drafting this as WSGI2, unless there is
> consensus here that the name should be different.

So - I'm going to state plainly my strong opposition to calling any
protocol WSGI that is not a straightforward evolution within the same
request-response paradigm we have to date, because it's just asking
for confusion.  The state of things is already confused enough,
without having two completely different paradigms assigned the same
name.  It's bad communications, bad marketing, and bad engineering.

I would much rather see WSGI be ultimately replaced entirely by its
"rich" (and hopefully cleaner) successor, following an appropriate
transition period.  And during that transition period, WSGI will serve
as the "simple use cases" API, with escapes allowed to richer APIs, as
a prelude to developing the successor spec.


> Your adapter sketch there is a useful escape hatch approach. It may
> have some use. However the downside is that its going to break on a
> lot of middleware.

Actually, it should be completely safe for middleware that doesn't
touch responses (or consume the wsgi.input), and for middleware that
does touch responses (e.g. to redirect to a login page) either hasn't
invoked the wrapped app at all, or is choosing to replace the response
entirely.  So I don't actually see where it's going to break much, if
at all.


> Really, I think we're agreeing on 95% here, but I'm biasing for having
> a majority of WSGI2 eventually, whereas you seem to be biasing for
> having a majority of WSGI indefinitely.

If you had, let's say three reasonably independent-of-each-other
HTTP/2 Python server API implementations right now, then I'd say it'd
be worthwhile starting on a RSGI spec.  However, since you've pointed
out only one, and noted it has paradigmatic limitations with respect
to ongoing developments in HTTP/2, the attempt to develop a de jure
specification seems not just premature, but extremely so.

If you want a solid Web-SIG consensus on something, I suggest that a
WSGI escape mechanism suitable for using both that HTTP/2 API and some
websocket APIs would be a much better bet.  I think that with the
participation of enough server developers, we could nail down a way to
let WSGI apps escape to *any* "native" server API, be it Twisted,
HTTP/2, tulip, or whatever, and get it blessed as a standard WSGI
extension pretty quickly.


> The reason I want to bias for
> the long term, is that it will be with us for a long while. We need to
> make incremental deployment easy - and that may well mean tunnelling
> some things.

There's no need to tunnel if you can bypass -- which ironically
enough, is what people already have started doing with websockets, and
which some of your own proposals have been about doing as well.

That is to say, you've actually convinced me that middleware bypass is
a *good* thing, for those things that cannot be sanely shoehorned into
the request/response paradigm.

Therefore, ISTM that by far the easiest way to "make incremental
deployment easy" is to provide a way to escape WSGI and revert to a
server's native API, whatever that API may be.  It cuts out the
following steps:

* Defining an API right away, based on insufficient usage experience
* Translating from a server's native API, to the defined API
* Translating *again*, from the defined API to current WSGI

While enabling the possibility for having *competition* among API
paradigms.  It also means that framework developers need not concern
themselves with the details of any new API, apart from possibly
documenting any special things their users need to know about escaping
to a native server API.


> The role of the spec here though is to define the
> protocol by which folk can write tunnellers *after* we get the thing
> working. Perhaps thats exactly what you mean: decouple an
> HTTP/2+Websockets+HTTP/1.x protocol from tunnelling new features
> through WSGI for legacy deployments. If thats what you mean, then I
> agree - and thats what I'm working on :)

Yes and no.  I'm saying that we should work immediately on providing
an *escape vector* for WSGI apps to say, "I want to jump out of WSGI
and instead use a richer API for handling this request"...

...so that you can begin *developing* the new thing in an environment
where it's easy to experiment with different APIs.

In essence, the app provides a response that says, "if you (the
server) get this response, then invoke the code I passed you earlier,
in order to begin the *real* response."  If the server doesn't see
such a response, it's treated as a normal WSGI response, and any
passed callbacks are discarded.  (Because it means it was from a
discarded or modified sub-request.)


> Ok, so implementor experience in the wild has taught us that this is a
> bad idea ;).

Yes -- *sequencing headers* is a bad idea.  Allowing apps *control
over what goes over the wire* was not.  ;-)

That being said, I don't have any issue with dicts being used for
headers in non-WSGI APIs.


> So that would/might address the breakiness but it wouldn't standardise
> the upgraded protocol(s) - the network effect is where the value is:
> folk can work around bugs on a case by case basis.

IMO, standardizing the upgraded protocol(s) is *very* premature.
"Rough consensus and running code" requires that there be more than
one instance of running code, to be in consensus.  ;-)


> Yeah, that really looks like the way forward: define a safe way to
>> escape WSGI from inside of it, so that server developers aren't forced
>> to dumb down HTTP/2 to WSGI, in order to provide rich HTTP/2 APIs.
>> What do you think?
>
> I worry that that leaves us with a lingua franca which we're expecting
> everyone to escape from.

Why would anybody who doesn't *need* HTTP/2 features *want* to escape it?

> That doesn't seem like a great place to aim

It's not an aim, it's a transitional path that allows us to start
without boiling the ocean.  Well, more of a lake than an ocean in this
case, but I think you're really underestimating the amount of work
needed to get a consensus HTTP/2 API put together, and if you base it
on present-day WSGI I think you're underestimating how much pushback
you'll get from existing implementors.  ;-)