Re: [whatwg/streams] Brainstorming a buffer-reusing version of writable streams (#495)

> What if something like a GrepTransformStream receives an ArrayBuffer containing, say, 3.5 lines of text. It then wants to give the consumer the 1st line and the 3rd, but not the 2nd, or the remainder which hasn't hit a 4th newline yet. They'd just be two views into the same underlying buffer. Detaching either would wreck the other right? What about a way to provide a reader with an array of views, all into the same buffer?

So, the GrepTransformStream has a writable byte stream (or non-byte stream with ArrayBuffer(View) chunks) for input and non-byte readable stream with ArrayBufferView chunks (each of them would contain a single line which hit the query in the form of a view with the ArrayBuffer written to the writable byte stream as underlying buffer) for output? That's good point, but for this use case, the spec doesn't require the output part to perform detaching for each output chunk separately since it's not a readable byte stream.

```
const writer = transformStream.writable.getWriter();  // or byte stream
writer.write(arrayBufferContainingMultipleLines);

const reader = transformStream.readable.getReader();
// The promise gets fulfilled with ArrayBufferViews pointing at matched lines
// backed by arrayBufferContainingMultipleLines.
const promise = reader.read();
```

So, the GrepTransformStream may delay fulfillment of read()s until all the bytes in the current input ArrayBuffer are processed and we're ready to detach the ArrayBuffer and then create ArrayBufferView instances backed with the ArrayBuffer, representing the grep result, and fulfill read()s.

This does delay fulfillment, but is equivalent to your proposal of providing a reader with an array of views, if I'm understanding your proposal correctly?

If not, could you please elaborate the situation?

-- 
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/streams/issues/495#issuecomment-257792629