Re: [whatwg/fetch] Getting all bytes in a body (#661)

> In the short-term, it looks like a bit of cut n' paste of "reading the body" language from from the Fetch standard to the HTML standard will solve the immediate issue. Is that what you are proposing?

Basically yes, although I'd like to locate it somewhere more reusable. Also, it would bridge away from promises and into "spec async".

But yes, I think that's the right short-term plan. I'm more confused about the long-term vision.

> What I'd like to avoid is adding explicit support for synchronous reading to the Streams standard. That's a big can of worms.

What about if it were done using a magic "wait" primitive which was only available "in parallel" (i.e. on background threads)? Well, still a pretty big can of worms, given you'd essentially be talking about manipulating the stream JS objects in parallel :-/. Yeah, let's not do that, at least not until I've really psyched myself up into believing it's clearly the best path forward...

> My understanding is that the glue between the Javascript world and the HTML world generally happens in the WebIDL standard. So in the longer term I'd like to see the ReadableStream glue moved from Fetch to WebIDL. I'd also like to add some extra glue for TransformStream, so we can avoid things like explicitly creating Promises and calling abstract operations in the Encoding standard.

Where it lives is less concerning to me than the model. Do we try to emulate Web IDL's style by treating streams as JS objects and then translating them into spec language? E.g. wrapping promises up into "spec async", or Uint8Arrays into Infra byte sequences. Or, do we try to say that there is some "byte stream" or "byte token sequences" concept that is more fundamental, and the JS API lives on top of?

> whether that is the way forward to resolve the streams/streams confusion.

I think that'll be a great first step. However I'm also worried about the byte sequences/token sequences confusion I discovered, where lots of other specs treat Encoding's algorithms as if they operate on static [byte sequences](https://infra.spec.whatwg.org/#byte-sequences), whereas Encoding defines them as operating on streams/token sequences that can change over time.

I think if we had more explicit static byte-sequence-taking endpoints in Encoding, it'd be clearer how much of encoding really needs "streaming" (i.e. token sequences) and thus how much of Encoding needs asynchronicity and all the attendant complexity.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/661#issuecomment-360018446