Readable stream with ack

[domenic]

An idea that keeps coming up (most recently #323, feel free to edit this post to point to other instances) is "readable stream with ack," i.e., one that not only lets you read(), but also lets you acknowledge when you're done with a chunk.

The most compelling case for this has to do with buffer re-use (e.g. #323). It also gives some symmetry with writable streams' two-signals approach (but see #316).

However, I find it basically impossible to envision author code using this correctly and consistently. @tyoshino, could you help illustrate some author code that operates like this?

[tyoshino]

However, I find it basically impossible to envision author code using this correctly and consistently.

I agree it's not easy to use. The user must be aware of some contract.

illustrate some author code

Sure

// Producer
let id = ...;  // Identity transform
let abv = ...;  // Data to write. Wanna get it back once I/O finishes consuming its contents.
let p = id.writable.write(abv);
p.then(abv => {
  // Reuse abv
});

// Consumer
let descriptor = id.readable.read();
let abv = descriptor.value;
sendToNetwork(abv).then(abv => {
  // Now, sendToNetwork finished consuming all the contents and returned
  // the ownership of the ArrayBuffer to us.
  descriptor.resolve(abv);
});

[tyoshino]

We could also manually do the equivalent by using a stream of tuples of { value, resolve, reject } and a strategy that looks at [[value]] when calculating size.

[domenic]

Sure

This is helpful since it illustrates that it's somewhat additive. That is, if we market it as "usually you will never get your array buffer back, but sometimes you might if the consumer is considerate and uses these extra APIs" then it seems more reasonable.

Do you envision usage outside of transform scenarios, or with non-byte streams? More examples always helps :)

We could also manually do the equivalent by using a stream of tuples of { value, resolve, reject } and a strategy that looks at [[value]] when calculating size.

Hmm that's interesting, and worth keeping in mind.

[tyoshino]

Seems the proposal at #329 (comment) (see also #329 (comment)) allows users to ignore complicated APIs (getByobReader() and getBufferLendingReader() (i.e. reader for read with ack)) and just use getReader() while allowing use of read with ack.