Re: [w3ctag/design-reviews] TextEncoderStream and TextDecoderStream (#282)

> The GenericTransformStream mixin creates readable and writeable properties, but it doesn't appears as though internal aspects of these default streams are configurable. That is, the various flags one can pass to Stream constructors aren't available for configuration when instantiating one of these stream types. This makes certain built-in stream types "magically" faster and perhaps more flexible than userland stream types, violating layering expectations. Perhaps there's a way to configure them that I've just missed?

I'm not sure I understand the question correctly. They're not magically faster. Implementations can take advantage of the fact that the internals are not visible to user JS to optimise these operations. But they wouldn't be faster because of features unavailable to JS; they'd be faster because of the absence of the dynamic behaviour provided by JS.

They're also not more flexible. A transform stream is just a readable and a writable glued together, and that is what GenericTransformStream is trying to express. That glue can be written in JS or anything else.

The polyfill at https://github.com/GoogleChromeLabs/text-encode-transform-polyfill has full feature parity with Chrome's implementation, which I think demonstrates that layering has not been broken.

The queuing strategies with which the streams are constructed are intentionally not configurable. To avoid adding buffer bloat to pipes, I made the queues as small as possible. My philosophy is that queuing strategies should be designed together with the transformer, as mismatches can have surprising side-effects.

> I'm not able to locate much in the way of example code outside of the encoding/streams/ WPT tests. There isn't a ton in the Explainer either. It'd be helpful to see examples that show problems being solved rather than just "how to use it here".

The first three demos at https://streams.spec.whatwg.org/demos/ use a polyfill of this functionality. Unfortunately it is out-of-date and doesn't match the final API. I am planning to update the demos to use the new polyfill, after which I can link them from the explainer.

It would good to have a longer example in the standard as well, maybe with the other long examples at the start of section 7. @annevk, what do you think?

> The Explainer states that it's a non-goal to provide encodings other than UTF-8. Is it possible to create your own subtype to handle other encodings? If not, why not?

You can create a TransformStream for any encoding you want, but you have to provide your own implementation. Encoding to encodings other than UTF-8 is intentionally not exposed to the web platform. It wouldn't be a subtype of TextEncoderStream, but I don't know why you'd want to do that anyway.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/282#issuecomment-434339285