[API design] Streaming upload API: push-style or pull-style?

[python-trio]

[API design] Streaming upload API: push-style or pull-style?

[njsmith]

Yeah, it's possible we'll want to make different decisions in a lower-level API. I'm not 100% sure it will make sense though. A low-level API doesn't have to be as comfortable to use or support retries, so those downsides don't apply. But we'd still need to figure out how to deal with the state complexity, and need some special-case mechanism to avoid aborting the request body when we get an early response.

We'll also need to double-check what grpc actually needs before committing to anything... my clever idea to make bidi HTTP look like an Upgrade/CONNECT is clever and all, but it still assumes that bidi HTTP users are OK with waiting for the response headers before they switch into bidi mode, and I'm actually not 100% sure whether that's true of grpc or not. (@standy66, do you know?)

Also, grpc only cares about bidi support over HTTP/2, and with HTTP/2 we don't need to abort the response body on early responses, so that whole issue goes away...

[sethmlarson]

I'm in complete agreement with the conclusion.

I wonder if there's a way we could include a push-based approach for a lower-level API, something that we've talked about a couple times about two layers of API: one that's basically ahip.request(...) (and all config objects like ahip.Retries()) for the 95% use-case and another for basically if grpc or the like want to use Hip. That's a far-future feature though.

[agronholm]

The way I thought about this was like how websockets are usually implemented. You write stuff to the request, read responses then. If you want to alternate between the two (extreme case: multipart request and response), you can. The server responding early is not a problem as I see it. If the user doesn't stop sending data after an early response, we can raise an exception when they try to send more.

As this implies, I strongly favor push-style over pull-style.