Re: [whatwg/encoding] Add Streams support (#72)

I have updated the proposed patch for the spec to make the TextEncoder & TextDecoder objects behave as stream transformers directly as we discussed here. Internally they delegate to a TransformStream object which provides the glue logic.

http://htmlpreview.github.io/?https://github.com/ricea/encoding-streams/blob/master/patch.html

@yhirano identified an issue during review. Consider the following code:

```javascript
let dec = new TextDecoder();
let writer = dec.writable.getWriter();
writer.write(incompleteByteSequence);
writer.releaseLock();
await doSomethingWith(dec.readable);
let what = dec.decode(moreBytes);
```

Here `dec.decode()` does not throw because the lock on `writable` was released. I am assuming that the lock on `readable` has also been released.

The issue is that the contents of `what` now depend on whether `doSomethingWith()` read from `readable` or not. TransformStream does not call `transform()` until a read happens, in order to respect backpressure[1]. If `doSomethingWith()` piped `readable` to a native stream it may be nondeterministic whether anything was read or not.

Our proposed solution is to make TextDecoder lock into a particular mode the first time `decode()` or the **decode and enqueue chunk** algorithm was called. Once it was locked into one mode attempting to use it the other way would be an error.

This doesn't make the above code deterministic, but it means that if `incompleteByteSequence` had indeed been processed then `decode()` would throw, which is hopefully better than producing garbage output.

Thoughts?

[1] This is a gross simplification.

-- 
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/encoding/issues/72#issuecomment-278578675