This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The purpose of size argument of read() are - allow user to get notified only when the specified size of data is available and get it as one non-fragmented ArrayBufferView - flow control. I.e. not to tell the producer to generate, receive from wire, etc. too much Current interface doesn't allow flow controlled consumption without specifying size N which means until N bytes become available, we don't get the result. read() without argument helps for this case, but it's unclear how many bytes read() pulls. If we differentiate exact read and non-exact read mode, we can give read() clearer semantics - read() in exact mode: Prohibit? - read(N) in exact mode: I can accept up to N bytes. tell me when exactly N bytes are available - read() in non-exact mode: tell me when any amount of data is available - read(N) in non-exact mode: I can accept up to N bytes. tell me when any bytes are available
Instead of bothering readType, have a separate method named readExact.
Done in preview ver https://dvcs.w3.org/hg/streams-api/raw-file/tip/preview.html
Looks like we lack say pipeExact() which is necessary for propagating pull requests.
read(N) in non-exact mode has been realized by pullAmount. pipeExact() is unnecessary. Available space of the destination is propagated by pipe() by setting pipePullAmount to the value.