Ho @yutakahirano - can you please update your explainer with a bit more detail? Please have a look at the explainer explainer for some detail on this. A good explainer should start with user needs - rather than developer needs. There's a purpose to this - to make sure the technologies we are adding to the web are build to meet user needs or solve user-facing problems. Thanks!

@torgo This allows web developers a way to upload unbounded streams. On the other hand, web developers can work around the current limitation, via multiple fetch requests or other APIs/protocols. There are other problems for such mitigations (more network resources, more latencies, extra developement cost for another protocol, etc.) but these are problems for developers, not for end-users. Hence it is difficult to state clear user benefits, although I believe the new feature ends up benefitting end-users in the end, via more efficiency and less developement cost.

Hi @yutakahirano that's great - can you please articulate that user benefit at the beginning of the explainer. Something like "More efficiency and lower development cost for streams means better, more performant, more reliable web applications when those web applications make use of streams."

Thanks, I updated the explainer.

Hi @yutakahirano, we had a discussion in our TAG meeting today. In the explainer, you mentioned that the current version support only "half-duplex" and the future version may support "full-duplex", is there any mechanism that deals with the compatibility of different versions?

Sorry for the delay!

Currently "half" is the only valid value, "full" is just mentioned in a note. Hence currently new Request('/', {duplex: 'full'}) throws an exception (if the browser supports streaming upload). When full-duplex streaming upload is specified and a browser starts supporting it, the browser will accept new Request('/', {duplex: 'full'}).

Hi @yutakahirano thanks for the updates. We'd like to see more detail on the user need and expected use cases for this. For example "Currently when users need to do xxx the situation is yyy. This creates problems because zzz. This technology solves these problems by qqq." This should be at the top of the document explaining what the new technology proposal is. We're also reviewing the API and we appreciate your feedback regarding the modes. Also thank you for going through the security & privacy questionnaire and providing answers. Can you bring this document into the same repo as the explainer please (rather than a google doc)?

Done: https://github.com/yutakahirano/fetch-with-streams/blob/master/streaming-upload-security-privacy-questionnaire.md

cc: @jakearchibald

Hi @yutakahirano thanks for the updated questionnaire responses.. I think we're still looking for some more info in the explainer relating to use cases and user need (from the end-user PoV)?

"Currently when users need to do xxx the situation is yyy. This creates problems because zzz. This technology solves these problems by qqq."

I think they are already explained in the doc.

The end-user benefit is described as:

These performance shortcomings and cost of additional logic will impact end-users. In other words, this feature will help end-users enjoy web applications with better performance, more reliability and less cost.

Sample use-cases are listed as:

• Web developers can upload unbounded data to the server.
• Web developers can implement streaming processing easily.

The kwown workarounds and their shortcomings are described at the Without the feature paragraph.

I like the current structure because xxx, yyy and zzz are long. If we had them in a single paragraph, it'd be very hard to understand the paragraph.

@yutakahirano Ok we're happy to close this on that basis. For reference: I think you do need to spend more time thinking about how to explain this feature and its benefits - especially when it gets documented in places like MDN where developers are not going to have the same context in their heads so may need a little more explanatory text. That's part of the point of asking for explainers, by the way.