streams VS url

Yup, this is what WHATWG's Streams spec[0] (linked in the article) says. It defines backpressure as a "process of normalizing flow from the original source according to how fast the chain can process chunks" where the reader "propagates a signal backwards through the pipe chain".

Mozilla's documentation[1] similarly defines backpressure as "the process by which a single stream or a pipe chain regulates the speed of reading/writing".

The article confuses backpressure (the signal used for regulation of the flow) with the reason backpressure is needed (producers and consumers working at different speeds). It should be fairly clear from the metaphor, I would have thought: With a pipe of unbounded size there is no pressure. The pressure builds up when consumer is slower than producer, which in turn slows down the producer. (Or the pipe explodes, or springs a leak and has to drop data on the ground.)

[0] https://streams.spec.whatwg.org/#pipe-chains

[1] https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...

// https://streams.spec.whatwg.org/#example-transform-identity const { writable, readable } = new TransformStream(); fetch("...", { body: readable }).then(response => /* ... */); const writer = writable.getWriter(); writer.write(new Uint8Array([0x73, 0x74, 0x72, 0x65, 0x61, 0x6D, 0x73, 0x21])); // "streams!" writer.close();

Yeah, in your case I think most of the complexity is actually on the ReadableStream side, not the base64 side.

The thing that I'd actually want for your case is either a TransformStream for byte stream <-> base64 stream (which I expect will come eventually, once the simple case gets done), or something which would let you read the entire stream into Uint8Array or ArrayBuffer, which is a long-standing suggestion [1].

---

> Why does de-chunking a byte array need to be complicated

Keep in mind the concat proposal is _very_ early. If you think it would be useful to be able to concat Uint8Arrays and have that implicitly concatenate the underlying buffers, [2] is the place to open an issue.

---

> You have made me realize I don't even know what the right venue is to vote on stuff. How should I signal to TC39 that e.g. Array.fromAsync is a good idea?

Unfortunately, it's different places for different things. Streams are not TC39 at all; the right place for suggestions there is in the WHATWG streams repo [3]. Usually there's already an existing issue and you can add your use case as a comment in the relevant issue. TC39 proposals all have their own Github repositories, and you can open a new issue with your use case.

Concrete use cases are much more helpful than just "this is a good idea". Though `fromAsync` in particular everyone agrees is good, and it mostly just needs implementations, which are ongoing; see e.g. [4]. If you _really_ want to advance a stage 3 proposal, you can contribute a PR to Chrome or Firefox with an implementation - but for nontrivial proposals that's usually hard. For TC39 in particular, use cases are only really valuable pre-stage-3 proposals.

[1] https://github.com/whatwg/streams/issues/1019

[2] https://github.com/jasnell/proposal-zero-copy-arraybuffer-li...

[3] https://github.com/whatwg/streams

[4] https://bugs.chromium.org/p/v8/issues/detail?id=13321

// AudioWorkletStream // Stream audio from Worker to AudioWorklet // guest271314 2-24-2020 let port; onmessage = async e => { 'use strict'; if (!port) { [port] = e.ports; port.onmessage = event => postMessage(event.data); } const { urls } = e.data; // https://github.com/whatwg/streams/blob/master/transferable-streams-explainer.md const { readable, writable } = new TransformStream(); (async _ => { for await (const _ of (async function* stream() { while (urls.length) { yield (await fetch(urls.shift(), {cache: 'no-store'})).body.pipeTo(writable, { preventClose: !!urls.length, }); } })()); })(); port.postMessage( { readable, }, [readable] ); };

Semicolon (;) has no special meaning in a URL. You can ascribe it a meaning in your particular routing, but the spec has nothing to say about it.

https://url.spec.whatwg.org/

https://github.com/whatwg/url/issues/577#issuecomment-118534...

It's not insurmountable absolutely and I would appreciate it absolutely.

For the query portion, it really depends if your are reading it server side or client side and using the WHATWG standard[0] which itself just mirrors convention. However, the standard dictating how a URL might be formed does not mandate anything about the query string that makes it parsable.

0]: https://url.spec.whatwg.org/#interface-urlsearchparams

Browsers have discrepancies too of course. Here's an interesting Chromium bug I've been following: https://bugs.chromium.org/p/chromium/issues/detail?id=125253... and an associated WHATWG discussion: https://github.com/whatwg/url/issues/606

Some multiple examples of browsers disagreeing: https://www.yagiz.co/url-parsing-and-browser-differences

What's imho missing is a size or count method. The reason they don't have one yet is because it's not clear whether it should be all tuples, or all keys. Discussion

Well, [text](href) is just a lousy syntax. Quite apart from how easy it is to forget which way round it is, the way round that it is is syntactically inferior: the parentheses are URL code points <https://url.spec.whatwg.org/#url-code-points>, so URL encoding won’t percent-encode parentheses, so Markdown doesn’t actually support all valid URLs, leading to injection attacks if all you do is regular URL encoding, deliberate or accidental, and deciding where an href ends is troublesome and inconsistent, with some Markdown implementations terminating at any right parenthesis, and others trying to match parentheses as a heuristic that helps most cases. The other way round, with the href in square brackets, would have been better in this regard, as square brackets aren’t URL code points, and thus will be percent-encoded. But better still would have been to lean on angle brackets more, matching long-held custom and the other style of links Markdown already uses (just plain ). In my own lightweight markup language that I’ve been working on for a while and am now polishing up and implementing properly, I’m currently using [text ]. [text] is also quite tempting, with slightly different trade-offs.

(When I speak of the details of URL encoding and which characters get percent-encoded, these things weren’t quite so clearly-defined back in 2004 as they are now, but I believe it was all still true.)

>A domain is a non-empty ASCII string that identifies a realm within a network. [RFC1034]

>The example.com and example.com. domains are not equivalent and typically treated as distinct.

https://url.spec.whatwg.org/#concept-domain