Re: [whatwg] Feedback wanted on integrating fetch request/response and streams

[Yutaka Hirano]

I'm fine with the body overloading.
IIUC no more overloading will be introduced: With streams, we will prefer
encoders / decoders integrated with streams more than adding overloads to
APIs, in order to support new types. So it is acceptable to add the last
overload here I think.

Thanks,

On Wed, Nov 5, 2014 at 7:01 PM, Domenic Denicola d...@domenic.me wrote:

 In https://github.com/yutakahirano/fetch-with-streams Yutaka, Anne, and I
 are working on how to integrate the fetch API with streams. The general
 pattern we want is that for both request and response objects their creator
 is given a writable stream to write body content to, using [the revealing
 constructor pattern][1]. (That way, for requests or responses created by
 the browser, developers can only read---not write---the bodies; for
 requests/responses created by the developer, the developer can do both.)

 The current fetch API when initializing with non-streaming bodies is
 roughly:

 ```js
 var req = new Request(http://example.com;, {
   method: POST,
   body: '{ json: here }' // or blob or FormData or ...
 });

 var res = new Response('{ json: here }' /* or blob or FormData or ...
 */, {
   status: 201,
   headers: { 'Content-Type': 'application/json' }
 });
 ```

 Note how in both cases the most important value is given an unlabeled
 position as the first argument: requests are about URLs, and responses
 are about bodies.

 Our current thought for streams integration is to overload the body
 position for each of these with a function that takes a writable stream:

 ```js
 var req = new Request(http://example.com;, {
   method: POST,
   body(stream) {
 stream.write(myArrayBuffer);
 stream.close();
   }
 });

 var res = new Response(
   stream = {
 someCSVStream.pipeThrough(new CSVToJsonTransform()).pipeTo(stream);
   },
   {
 status: 201,
 headers: { 'Content-Type': 'application/json' }
   }
 );
 ```

 Do we think this is good? Any other ideas?

 Personally I find the overloads weird, especially since they behave
 completely differently when passing a string versus passing a function. But
 after thinking through this for a while I didn't have any better ideas that
 worked for both requests and responses.

 [1]: https://blog.domenic.me/the-revealing-constructor-pattern/

[whatwg] Feedback wanted on integrating fetch request/response and streams

[Domenic Denicola]

In https://github.com/yutakahirano/fetch-with-streams Yutaka, Anne, and I are 
working on how to integrate the fetch API with streams. The general pattern we 
want is that for both request and response objects their creator is given a 
writable stream to write body content to, using [the revealing constructor 
pattern][1]. (That way, for requests or responses created by the browser, 
developers can only read---not write---the bodies; for requests/responses 
created by the developer, the developer can do both.)

The current fetch API when initializing with non-streaming bodies is roughly:

```js
var req = new Request(http://example.com;, {
  method: POST,
  body: '{ json: here }' // or blob or FormData or ...
});

var res = new Response('{ json: here }' /* or blob or FormData or ... */, {
  status: 201,
  headers: { 'Content-Type': 'application/json' }
});
```

Note how in both cases the most important value is given an unlabeled 
position as the first argument: requests are about URLs, and responses are 
about bodies.

Our current thought for streams integration is to overload the body position 
for each of these with a function that takes a writable stream:

```js
var req = new Request(http://example.com;, {
  method: POST,
  body(stream) {
stream.write(myArrayBuffer);
stream.close();
  }
});

var res = new Response(
  stream = {
someCSVStream.pipeThrough(new CSVToJsonTransform()).pipeTo(stream);
  },
  {
status: 201,
headers: { 'Content-Type': 'application/json' }
  }
);
```

Do we think this is good? Any other ideas?

Personally I find the overloads weird, especially since they behave completely 
differently when passing a string versus passing a function. But after thinking 
through this for a while I didn't have any better ideas that worked for both 
requests and responses.
 
[1]: https://blog.domenic.me/the-revealing-constructor-pattern/