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

> If it used a transform stream that did the same type of text decoding, you'd have the same problem, with what being 'blue_heart' vs. '\ufffd'.

This is not the case. As long as the writes are all done via the WritableStream interface, the output will always be  '💙'. The problem only happens when sometimes writing via the WritableStream's queue and sometimes bypassing it.

> But I'd argue that to the user, by reusing the same object, you've created an expectation that they share the same internal queues.

This is a fair point. But I don't think it would make sense to attempt to mix the APIs on the same object. Most people wouldn't even attempt it. So my preferred approach is to help the few people who do attempt to mix the APIs by making it obviously not work, rather than failing in subtle and confusing ways.

> If we don't think reusing the same internal queues is feasible

- If we chose to implement a real sync API, then backpressure needs to work differently and I don't know how to make that work together with the existing async backpressure.
- If we chose to munge the writable stream queue, we'd need to check whether the stream is already CLOSING, resolve the promises on pending writes, update backpressure, and probably a bunch of other bookkeeping I'm forgetting. Because of the subtleties in the WritableStream state model I'd need an extraordinary number of tests to be confident it worked.

> separate objects, e.g. TextDecoder.stream() vending a vanilla TransformStream with its own queues, instead of making TextDecoder into hybrid object.

I can see the attraction of the purity of this solution, but looked at from the user's perspective it's just pure cognitive overload. The existence and name of that method is just one more thing they need to remember.

We'd also lose the "encoding", "fatal" and "ignoreBOM" attributes, but I've no idea whether that matters.

>From the point of view of the standard text, we need to somehow delegate to the TextDecoder constructor, passing on the arguments. It seems awkward.

I talked about it with @yhirano offline, and he convinced me that the approach of a static method returning a TransformStream is not that bad. If other people agree that's the way to go, I can make it work.

> `stream()` ends up creating an object which you can definitely create through a constructor. It's basically a shortcut for `new TransformStream({ ... transformer that uses a new TextDecoder ... })`.)

It doesn't really work that way since we added [CreateTransformStream](https://streams.spec.whatwg.org/#create-transform-stream). We won't be creating a hidden object, just a bunch of abstract algorithms that are associated with the TextDecoder object.

-- 
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-368037598