Representing Fetch' body concept in streams

[annevk]

Aside from using enqueue, don't we also need to turn each mention of body into writable/readable stream pair?

[yutakahirano]

The current fetch spec defines request body and response body as "byte streams" which I understand as byte sequences. Currently my draft does not change it but specifies bodies of type Readable[Byte]Stream in Body mixin. Do you intend to change that and move everything to the streams-based world?

[domenic]

In particular note how @yutakahirano's approach is to use the "response body" as a staging area for bytes before they are enqueued into the ReadableByteStream, as in e.g. the "To process response body for response, run these substeps" algorithm.

[wanderview]

Aside from using enqueue, don't we also need to turn each mention of body into writable/readable stream pair?

I thought we had decided not to treat it as a writable stream. :-) Or maybe thats just my wishful thinking.

[annevk]

@yutakahirano well the Fetch stream-based world is streams that have both input and output simultaneously, similar to the Encoding Standard. I was thinking we needed to reconcile that somehow?

[annevk]

Maybe I am not understand something, but even if both bodies are a readable stream, there's an input side as well right? For Response that is the network or a service worker. For Request that is the window/worker? I was assuming that is some kind of writable stream we would need to model.

If just saying they are ReadableByteStream is enough, works form me.

[wanderview]

Maybe I am not understand something, but even if both bodies are a readable stream, there's an input side as well right?

Yea, ok, but I think this "writable side" should be purely conceptual. For example, the Response.body stream will read directly from the disk. There is no pipe writing in that case.

[wanderview]

I think it would be easiest to always specify the body as a ReadableStream. If the producer of a Response or Request needs to push data then their algorithm is written with a pipe. So Cache just sets a ReadableStream representing a file. The fetch algorithm creates a pipe, passes its Reader end as Response.body, and then enqueues to the writer end.

[yutakahirano]

@annevk This discussion will be affected by #30 which is not settled yet (I'm sorry I've been away from the discussion for a week). Can we discuss this after #30 settles?

[annevk]

I'm not in a rush.

[annevk]

(Note that within this issue I was not talking about the body property from Request and Response. But about the abstract body concept attached to the abstract request and response concepts. Rereading I'm not sure that was clear.)

[yutakahirano]

I created two issues #40 and #41 because specifying on request and response are independent each other.

[tyoshino]

Shall we just close this issue?

[yutakahirano]

Sure, let's discuss on branched threads.