Thanks Matthew, you are much easier to read than the spec! FYI, if I don't respond, it is because this interface has no "like" button - and I only work some days in the week. I am appreciative! So to paraphrase, my new understanding - the controller manages the internal queues of the stream. - A consumer (e.g. a reader or a another stream in a pipe chain) requests data from the stream, for example using `read`. This creates a "pending request" - if the internal queue has data the stream will satisfy the pending request from that (and won't request more from the source using `pull()`) - However if the stream has no data in the queue the controller will try pull more. Essentially this means that it _may _create a `ReadableStreamBYOBRequest` and call `pull()` if it is defined. - It will create `ReadableStreamBYOBRequest` IFF either of the reasons you gave are true (the reader was created as byob OR autoallocation buffer is defined). Otherwise this will be `null`. It will also be `null` when there is no pending request, which implies the item gets deleted whenever a pending request is satisfied. - A source has three choices. - It can always enqueue its data using the controller. - IFF the BYOBRequest is not NULL it can write to the supplied buffer using `respond()` - IFF the BYOBRequest is not NULL it can supply its own buffer and send that in `respondWithNew()`. - So if you have a BYOBRequest it means you're doing a zero-copy transfer to the **consumer's buffer**. If you don't then you're copying into an internal buffer and the data is later copied when needed. 1. Sound about right? The big epiphany for me here was what was meant by zero copy - not of source buffer into controller queue, but of source buffer into the final consumers buffer. So `view` is an auto allocated buffer that you plan to give the final consumer with `respond()` but you might instead give them your own buffer using `respondNew()`. 2. Doesn't that mean that you may allocate a buffer for the view that you then throw away because you responded with your own buffer? >> If you have a push source and so you don't define a pull() how does BYOB work? > I... don't think it works? Experimentally, rs = new ReadableStream({start(controller) { console.log(typeof controller.byobRequest.view) }, autoAllocateChunkSize: 1024, type: 'bytes'}) throws, because byobRequest is undefined. So just FYI, I think this means this test is invalid, because you won't have a `byobRequest` unless the data is requested and unavailable. But you answered this by pointing me to the first example. My epiphany here was that the controller doesn't care if the source is push or pull. If it needs data it creates the request. So a push source should write to the request if it has one, and otherwise enqueue. A pull source differs only in that it will probably have the request. 3. Make sense. I think I might actually get this. A miracle!
Bug 1767342 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Thanks Matthew, you are much easier to read than the spec! FYI, if I don't respond, it is because this interface has no "like" button - and I only work some days in the week. I am appreciative! So to paraphrase, my new understanding - the controller manages the internal queues of the stream. - A consumer (e.g. a reader or a another stream in a pipe chain) requests data from the stream, for example using `read`. This creates a "pending request" - if the internal queue has data the stream will satisfy the pending request from that (and won't request more from the source using `pull()`) - However if the stream has no data in the queue the controller will try pull more. Essentially this means that it _may _create a `ReadableStreamBYOBRequest` and call `pull()` if it is defined. - It will create `ReadableStreamBYOBRequest` IFF either of the reasons you gave are true (the reader was created as byob OR autoallocation buffer is defined). Otherwise this will be `null`. It will also be `null` when there is no pending request, which implies the item gets deleted whenever a pending request is satisfied. - A source has three choices. - It can always enqueue its data using the controller. - IFF the BYOBRequest is not NULL it can write to the supplied buffer using `respond()` - IFF the BYOBRequest is not NULL it can supply its own buffer and send that in `respondWithNew()`. - So if you have a BYOBRequest it means you're doing a zero-copy transfer to the **consumer's buffer**. If you don't then you're copying into an internal buffer and the data is later copied when needed. 1. Sound about right? The big epiphany for me here was what was meant by zero copy - not of source buffer into controller queue, but of source buffer into the final consumers buffer. So `view` is an auto allocated buffer that you plan to give the final consumer with `respond()` but you might instead give them your own buffer using `respondNew()`. 2. Doesn't that mean that you may allocate a buffer for the view that you then throw away because you responded with your own buffer? >> If you have a push source and so you don't define a pull() how does BYOB work? > I... don't think it works? Experimentally, rs = new ReadableStream({start(controller) { console.log(typeof controller.byobRequest.view) }, autoAllocateChunkSize: 1024, type: 'bytes'}) throws, because byobRequest is undefined. So just FYI, I think this means this test is invalid, because you won't have a `byobRequest` unless the data is requested and unavailable. But you answered this by pointing me to the first example. My epiphany here was that the controller doesn't care if the source is push or pull. If it needs data it creates the request. So a push source should write to the request if it has one, and otherwise enqueue. A pull source differs only in that it will probably have the request. 3. Make sense? 4. Is the zero copy just to the immediate consumer or the ultimate sync? My assumption is the immediate consumer - i.e a transform stream would need to provide a new buffer. I think I might actually get this. A miracle!
Thanks Matthew, you are much easier to read than the spec! FYI, if I don't respond, it is because this interface has no "like" button - and I only work some days in the week. I am appreciative! So to paraphrase, my new understanding - the controller manages the internal queues of the stream. - A consumer (e.g. a reader or a another stream in a pipe chain) requests data from the stream, for example using `read`. This creates a "pending request" - if the internal queue has data the stream will satisfy the pending request from that (and won't request more from the source using `pull()`) - However if the stream has no data in the queue the controller will try pull more. Essentially this means that it _may _create a `ReadableStreamBYOBRequest` and call `pull()` if it is defined. - It will create `ReadableStreamBYOBRequest` IFF either of the reasons you gave are true (the reader was created as byob OR autoallocation buffer is defined). Otherwise this will be `null`. It will also be `null` when there is no pending request, which implies the item gets deleted whenever a pending request is satisfied. - A source has three choices. - It can always enqueue its data using the controller. - IFF the BYOBRequest is not NULL it can write to the supplied buffer using `respond()` - IFF the BYOBRequest is not NULL it can supply its own buffer and send that in `respondWithNew()`. - So if you have a BYOBRequest it means you're doing a zero-copy transfer to the **consumer's buffer**. If you don't then you're copying into an internal buffer and the data is later copied when needed. 1. Sound about right? The big epiphany for me here was what was meant by zero copy - not of source buffer into controller queue, but of source buffer into the final consumers buffer. So `view` is an auto allocated buffer that you plan to give the final consumer with `respond()` but you might instead give them your own buffer using `respondNew()`. 2. Doesn't that mean that you may allocate a buffer for the view that you then throw away because you responded with your own buffer? >> If you have a push source and so you don't define a pull() how does BYOB work? > I... don't think it works? Experimentally, rs = new ReadableStream({start(controller) { console.log(typeof controller.byobRequest.view) }, autoAllocateChunkSize: 1024, type: 'bytes'}) throws, because byobRequest is undefined. So just FYI, I think this means this test is invalid, because you won't have a `byobRequest` unless the data is requested and unavailable. But you answered this by pointing me to the first example. My epiphany here was that the controller doesn't care if the source is push or pull. If it needs data it creates the request. So a push source should write to the request if it has one, and otherwise enqueue. A pull source differs only in that it will probably have the request. 3. Make sense? 4. Is the zero copy just to the immediate consumer or the ultimate sync? My assumption is the immediate consumer - i.e a transform stream would need to provide a new buffer. 5. Above I referred to zero copying to the consumer's buffer, and I was thinking this could be any type of consumer - i.e. pipe to a writable stream or a default reader or a `ReadableStreamBYOBReader`. As opposed to only being aware of byte consumers like `ReadableStreamBYOBReader`. Am I correct? I think the only special thing about a `ReadableStreamBYOBReader` is that it will supply the `BYOBRequest` when needed because it knows that you want that, whether or not the underlying source has specified itself as a byte source. For any other consumer, you'll get a buffer, it might come to you as zero copy. You really don't know or care. Right? I think I might actually get this. A miracle!
Thanks Matthew, you are much easier to read than the spec! FYI, if I don't respond, it is because this interface has no "like" button - and I only work some days in the week. I am appreciative! So to paraphrase, my new understanding - the controller manages the internal queues of the stream. - A consumer (e.g. a reader or a another stream in a pipe chain) requests data from the stream, for example using `read`. This creates a "pending request" - if the internal queue has data the stream will satisfy the pending request from that (and won't request more from the source using `pull()`) - However if the stream has no data in the queue the controller will try pull more. Essentially this means that it _may _create a `ReadableStreamBYOBRequest` and call `pull()` if it is defined. - It will create `ReadableStreamBYOBRequest` IFF either of the reasons you gave are true (the reader was created as byob OR autoallocation buffer is defined). Otherwise this will be `null`. It will also be `null` when there is no pending request, which implies the item gets deleted whenever a pending request is satisfied. - A source has three choices. - It can always enqueue its data using the controller. - IFF the BYOBRequest is not NULL it can write to the supplied buffer using `respond()` - IFF the BYOBRequest is not NULL it can supply its own buffer and send that in `respondWithNew()`. - So if you have a BYOBRequest it means you're doing a zero-copy transfer to the **consumer's buffer**. If you don't then you're copying into an internal buffer and the data is later copied when needed. 1. Sound about right? The big epiphany for me here was what was meant by zero copy - not of source buffer into controller queue, but of source buffer into the final consumers buffer. So `view` is an auto allocated buffer that you plan to give the final consumer with `respond()` but you might instead give them your own buffer using `respondNew()`. 2. Doesn't that mean that you may allocate a buffer for the view that you then throw away because you responded with your own buffer? >> If you have a push source and so you don't define a pull() how does BYOB work? > I... don't think it works? Experimentally, rs = new ReadableStream({start(controller) { console.log(typeof controller.byobRequest.view) }, autoAllocateChunkSize: 1024, type: 'bytes'}) throws, because byobRequest is undefined. So just FYI, I think this means this test is invalid, because you won't have a `byobRequest` unless the data is requested and unavailable. But you answered this by pointing me to the first example. My epiphany here was that the controller doesn't care if the source is push or pull. If it needs data it creates the request. So a push source should write to the request if it has one, and otherwise enqueue. A pull source differs only in that it will probably have the request. 3. Make sense? 4. Is the zero copy just to the immediate consumer or the ultimate sync? My assumption is the immediate consumer - i.e a transform stream would need to provide a new buffer. 5. Above I referred to zero copying to the consumer's buffer, and I was thinking this could be any type of consumer - i.e. pipe to a writable stream or a default reader or a `ReadableStreamBYOBReader`. As opposed to only being aware of byte consumers like `ReadableStreamBYOBReader`. Am I correct? I think the only special thing about a `ReadableStreamBYOBReader` is that it will supply the `BYOBRequest` when needed because it knows that you want that, whether or not the underlying source has specified itself as a byte source. For any other consumer, you'll get a buffer, it might come to you as zero copy. You really don't know or care. Right? 6. You noted two conditions under which the request is created. Might it be more precise to say that those are the two conditions under which a ReadableByteStreamController is created? Otherwise you get a default controller, which doesn't even have a the request? I ask because that would make it easier for me to write the docs :-) I think I might actually get this. A miracle!
Thanks Matthew, you are much easier to read than the spec! FYI, if I don't respond, it is because this interface has no "like" button - and I only work some days in the week. I am appreciative! So to paraphrase, my new understanding - the controller manages the internal queues of the stream. - A consumer (e.g. a reader or a another stream in a pipe chain) requests data from the stream, for example using `read`. This creates a "pending request" - if the internal queue has data the stream will satisfy the pending request from that (and won't request more from the source using `pull()`) - However if the stream has no data in the queue the controller will try pull more. Essentially this means that it _may _create a `ReadableStreamBYOBRequest` and call `pull()` if it is defined. - It will create `ReadableStreamBYOBRequest` IFF either of the reasons you gave are true (the reader was created as byob OR autoallocation buffer is defined). Otherwise this will be `null`. It will also be `null` when there is no pending request, which implies the item gets deleted whenever a pending request is satisfied. - A source has three choices. - It can always enqueue its data using the controller. - IFF the BYOBRequest is not NULL it can write to the supplied buffer using `respond()` - IFF the BYOBRequest is not NULL it can supply its own buffer and send that in `respondWithNew()`. - So if you have a BYOBRequest it means you're doing a zero-copy transfer to the **consumer's buffer**. If you don't then you're copying into an internal buffer and the data is later copied when needed. 1. Sound about right? The big epiphany for me here was what was meant by zero copy - not of source buffer into controller queue, but of source buffer into the final consumers buffer. So `view` is an auto allocated buffer that you plan to give the final consumer with `respond()` but you might instead give them your own buffer using `respondNew()`. 2. Doesn't that mean that you may allocate a buffer for the view that you then throw away because you responded with your own buffer? >> If you have a push source and so you don't define a pull() how does BYOB work? > I... don't think it works? Experimentally, rs = new ReadableStream({start(controller) { console.log(typeof controller.byobRequest.view) }, autoAllocateChunkSize: 1024, type: 'bytes'}) throws, because byobRequest is undefined. So just FYI, I think this means this test is invalid, because you won't have a `byobRequest` unless the data is requested and unavailable. But you answered this by pointing me to the first example. My epiphany here was that the controller doesn't care if the source is push or pull. If it needs data it creates the request. So a push source should write to the request if it has one, and otherwise enqueue. A pull source differs only in that it will probably have the request. 3. Make sense? 4. Is the zero copy just to the immediate consumer or the ultimate sync? My assumption is the immediate consumer - i.e a transform stream would need to provide a new buffer. 5. Above I referred to zero copying to the consumer's buffer, and I was thinking this could be any type of consumer - i.e. pipe to a writable stream or a default reader or a `ReadableStreamBYOBReader`. As opposed to only being aware of byte consumers like `ReadableStreamBYOBReader`. Am I correct? I think the only special thing about a `ReadableStreamBYOBReader` is that it will supply the `BYOBRequest` when needed because it knows that you want that, whether or not the underlying source has specified itself as a byte source. For any other consumer, you'll get a buffer, it might come to you as zero copy. You really don't know or care. Right? 6. You noted two conditions under which the request is created. Might it be more precise to say that those are the two conditions under which a `ReadableByteStreamController` is created (otherwise you get a default controller, which doesn't even have a the request property)? That makes sense because you can create the stream using autoallocatebuffer and get teh request, and still read it using the default reader (hope what I mean makes sense) I think I might actually get this. A miracle!
Thanks Matthew, you are much easier to read than the spec! FYI, if I don't respond, it is because this interface has no "like" button - and I only work some days in the week. I am appreciative! So to paraphrase, my new understanding - the controller manages the internal queues of the stream. - A consumer (e.g. a reader or a another stream in a pipe chain) requests data from the stream, for example using `read`. This creates a "pending request" - if the internal queue has data the stream will satisfy the pending request from that (and won't request more from the source using `pull()`) - However if the stream has no data in the queue the controller will try pull more. Essentially this means that it _may _create a `ReadableStreamBYOBRequest` and call `pull()` if it is defined. - It will create `ReadableStreamBYOBRequest` IFF either of the reasons you gave are true (the reader was created as byob OR autoallocation buffer is defined). Otherwise this will be `null`. It will also be `null` when there is no pending request, which implies the item gets deleted whenever a pending request is satisfied. - A source has three choices. - It can always enqueue its data using the controller. - IFF the BYOBRequest is not NULL it can write to the supplied buffer using `respond()` - IFF the BYOBRequest is not NULL it can supply its own buffer and send that in `respondWithNew()`. - So if you have a BYOBRequest it means you're doing a zero-copy transfer to the **consumer's buffer**. If you don't then you're copying into an internal buffer and the data is later copied when needed. 1. Sound about right? The big epiphany for me here was what was meant by zero copy - not of source buffer into controller queue, but of source buffer into the final consumers buffer. So `view` is an auto allocated buffer that you plan to give the final consumer with `respond()` but you might instead give them your own buffer using `respondNew()`. 2. Doesn't that mean that you may allocate a buffer for the view that you then throw away because you responded with your own buffer? >> If you have a push source and so you don't define a pull() how does BYOB work? > I... don't think it works? Experimentally, rs = new ReadableStream({start(controller) { console.log(typeof controller.byobRequest.view) }, autoAllocateChunkSize: 1024, type: 'bytes'}) throws, because byobRequest is undefined. So just FYI, I think this means this test is invalid, because you won't have a `byobRequest` unless the data is requested and unavailable. But you answered this by pointing me to the first example. My epiphany here was that the controller doesn't care if the source is push or pull. If it needs data it creates the request. So a push source should write to the request if it has one, and otherwise enqueue. A pull source differs only in that it will probably have the request. 3. Make sense? 4. Is the zero copy just to the immediate consumer or the ultimate sync? My assumption is the immediate consumer - i.e a transform stream would need to provide a new buffer. 5. Above I referred to zero copying to the consumer's buffer, and I was thinking this could be any type of consumer - i.e. pipe to a writable stream or a default reader or a `ReadableStreamBYOBReader`. As opposed to only being aware of byte consumers like `ReadableStreamBYOBReader`. Am I correct? I think the only special thing about a `ReadableStreamBYOBReader` is that it will supply the `BYOBRequest` when needed because it knows that you want that, whether or not the underlying source has specified itself as a byte source. For any other consumer, you'll get a buffer, it might come to you as zero copy. You really don't know or care. Right? 6. You noted two conditions under which the request is created. Might it be more precise to say that those are the two conditions under which a `ReadableByteStreamController` is created (otherwise you get a default controller, which doesn't even have a the request property)? That makes sense because you can create the stream using autoallocatebuffer and get teh request, and still read it using the default reader (hope what I mean makes sense) 7. Related to point 6, you said "The stream was created with an autoAllocateChunkSize, in which case the byobRequest is always present". I think you mean "in this case you may get a byobRequest" - I don't think you can have a request unless the internal buffers are empty. So this support the idea that maybe you mean `ReadableByteStreamController` is supplied which has the property. I think I might actually get this. A miracle!
Thanks Matthew, you are much easier to read than the spec! FYI, if I don't respond, it is because this interface has no "like" button - and I only work some days in the week. I am appreciative! So to paraphrase, my new understanding - the controller manages the internal queues of the stream. - A consumer (e.g. a reader or a another stream in a pipe chain) requests data from the stream, for example using `read`. This creates a "pending request" - if the internal queue has data the stream will satisfy the pending request from that (and won't request more from the source using `pull()`) - However if the stream has no data in the queue the controller will try pull more. Essentially this means that it _may _create a `ReadableStreamBYOBRequest` and call `pull()` if it is defined. - It will create `ReadableStreamBYOBRequest` IFF either of the reasons you gave are true (the reader was created as byob OR autoallocation buffer is defined). Otherwise this will be `null`. It will also be `null` when there is no pending request, which implies the item gets deleted whenever a pending request is satisfied. - A source has three choices. - It can always enqueue its data using the controller. - IFF the BYOBRequest is not NULL it can write to the supplied buffer using `respond()` - IFF the BYOBRequest is not NULL it can supply its own buffer and send that in `respondWithNew()`. - So if you have a BYOBRequest it means you're doing a zero-copy transfer to the **consumer's buffer**. If you don't then you're copying into an internal buffer and the data is later copied when needed. 1. Sound about right? The big epiphany for me here was what was meant by zero copy - not of source buffer into controller queue, but of source buffer into the final consumers buffer. So `view` is an auto allocated buffer that you plan to give the final consumer with `respond()` but you might instead give them your own buffer using `respondNew()`. 2. Doesn't that mean that you may allocate a buffer for the view that you then throw away because you responded with your own buffer? >> If you have a push source and so you don't define a pull() how does BYOB work? > I... don't think it works? Experimentally, rs = new ReadableStream({start(controller) { console.log(typeof controller.byobRequest.view) }, autoAllocateChunkSize: 1024, type: 'bytes'}) throws, because byobRequest is undefined. So just FYI, I think this means this test is invalid, because you won't have a `byobRequest` unless the data is requested and unavailable. But you answered this by pointing me to the first example. My epiphany here was that the controller doesn't care if the source is push or pull. If it needs data it creates the request. So a push source should write to the request if it has one, and otherwise enqueue. A pull source differs only in that it will probably have the request. 3. Make sense? 4. Is the zero copy just to the immediate consumer or the ultimate sync? My assumption is the immediate consumer - i.e a transform stream would need to provide a new buffer. 5. Above I referred to zero copying to the consumer's buffer, and I was thinking this could be any type of consumer - i.e. pipe to a writable stream or a default reader or a `ReadableStreamBYOBReader`. As opposed to only being aware of byte consumers like `ReadableStreamBYOBReader`. Am I correct? I think the only special thing about a `ReadableStreamBYOBReader` is that it will supply the `BYOBRequest` when needed because it knows that you want that, whether or not the underlying source has specified itself as a byte source. For any other consumer, you'll get a buffer, it might come to you as zero copy. You really don't know or care. Right? 6. You noted two conditions under which the request is created. Might it be more precise to say that those are the two conditions under which a `ReadableByteStreamController` is created (otherwise you get a default controller, which doesn't even have a the request property)? That makes sense because you can create the stream using autoallocatebuffer and get teh request, and still read it using the default reader (hope what I mean makes sense) 7. Related to point 6, you said "The stream was created with an autoAllocateChunkSize, in which case the byobRequest is always present". I think you mean "in this case you may get a byobRequest" - I don't think you can have a request unless the internal buffers are empty. So this support the idea that maybe you mean `ReadableByteStreamController` is supplied which has the property. I think I might actually get this. A miracle! Would be good if you could sanity check the first doc based on above assumptions https://github.com/mdn/content/pull/16818/commits/4d9101722fca49e5dbc189938ba32bca2be7fb97
Thanks Matthew, you are much easier to read than the spec! FYI, if I don't respond, it is because this interface has no "like" button - and I only work some days in the week. I am appreciative! So to paraphrase, my new understanding - the controller manages the internal queues of the stream. - A consumer (e.g. a reader or a another stream in a pipe chain) requests data from the stream, for example using `read`. This creates a "pending request" - if the internal queue has data the stream will satisfy the pending request from that (and won't request more from the source using `pull()`) - However if the stream has no data in the queue the controller will try pull more. Essentially this means that it _may _create a `ReadableStreamBYOBRequest` and call `pull()` if it is defined. - It will create `ReadableStreamBYOBRequest` IFF either of the reasons you gave are true (the reader was created as byob OR autoallocation buffer is defined). Otherwise this will be `null`. It will also be `null` when there is no pending request, which implies the item gets deleted whenever a pending request is satisfied. - A source has three choices. - It can always enqueue its data using the controller. - IFF the BYOBRequest is not NULL it can write to the supplied buffer using `respond()` - IFF the BYOBRequest is not NULL it can supply its own buffer and send that in `respondWithNew()`. - So if you have a BYOBRequest it means you're doing a zero-copy transfer to the **consumer's buffer**. If you don't then you're copying into an internal buffer and the data is later copied when needed. 1. Sound about right? The big epiphany for me here was what was meant by zero copy - not of source buffer into controller queue, but of source buffer into the final consumers buffer. So `view` is an auto allocated buffer that you plan to give the final consumer with `respond()` but you might instead give them your own buffer using `respondNew()`. 2. Doesn't that mean that you may allocate a buffer for the view that you then throw away because you responded with your own buffer? >> If you have a push source and so you don't define a pull() how does BYOB work? > I... don't think it works? Experimentally, rs = new ReadableStream({start(controller) { console.log(typeof controller.byobRequest.view) }, autoAllocateChunkSize: 1024, type: 'bytes'}) throws, because byobRequest is undefined. So just FYI, I think this means this test is invalid, because you won't have a `byobRequest` unless the data is requested and unavailable. But you answered this by pointing me to the first example. My epiphany here was that the controller doesn't care if the source is push or pull. If it needs data it creates the request. So a push source should write to the request if it has one, and otherwise enqueue. A pull source differs only in that it will probably have the request. 3. Make sense? 4. Is the zero copy just to the immediate consumer or the ultimate sync? My assumption is the immediate consumer - i.e a transform stream would need to provide a new buffer. 5. Above I referred to zero copying to the consumer's buffer, and I was thinking this could be any type of consumer - i.e. pipe to a writable stream or a default reader or a `ReadableStreamBYOBReader`. As opposed to only being aware of byte consumers like `ReadableStreamBYOBReader`. Am I correct? I think the only special thing about a `ReadableStreamBYOBReader` is that it will supply the `BYOBRequest` when needed because it knows that you want that, whether or not the underlying source has specified itself as a byte source. For any other consumer, you'll get a buffer, it might come to you as zero copy. You really don't know or care. Right? 6. You noted two conditions under which the request is created. Might it be more precise to say that those are the two conditions under which a `ReadableByteStreamController` is created (otherwise you get a default controller, which doesn't even have a the request property)? That makes sense because you can create the stream using autoallocatebuffer and get teh request, and still read it using the default reader (hope what I mean makes sense) 7. Related to point 6, you said "The stream was created with an autoAllocateChunkSize, in which case the byobRequest is always present". I think you mean "in this case you may get a byobRequest" - I don't think you can have a request unless the internal buffers are empty. So this support the idea that maybe you mean `ReadableByteStreamController` is supplied which has the property. I think I might actually get this. A miracle! Would be good if you could sanity check the first doc based on above assumptions: [ReadableStreamBYOBRequest](https://pr16818.content.dev.mdn.mozit.cloud/en-US/docs/Web/API/ReadableStreamBYOBRequest)