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

> This type can't be meaninfully subclassed in script.

By "this type", do you mean TransformStreamDefaultController? It can't be meaningfully subclassed, because it is only useful when it is associated with a TransformStream object.

> What are the extension points to make a BYO transform stream type?

A transform stream is simply an object that has a `readable` property that is a ReadableStream and a `writable` property that is a WritableStream. You can create one however you like. The TransformStream constructor provides one convenient method to do so.

> the choices you're making about buffer sizes might be right, but sophisticated users might take different views. Where are the extension points for those?

You can always add buffering to a pipe using identity transforms. For example, suppose you want a megabyte of buffering in front of a TextDecoderStream:
```javascript
const bufferingIdentityTransform =
    new TransformStream({}, new ByteLengthQueuingStrategy({highWaterMark: 1024 * 1024}));

response.body
  .pipeThrough(bufferingIdentityTransform)
  .pipeThrough(new TextDecoderStream())
  .pipeTo(mySink);
```
> Not having configurable queueing strategies might, again, be the right default choice. But always? In all cases? What about for other types?

There might be other platform transforms for which a configurable queuing strategy would make sense. There would be a price to pay in that the user-supplied `size()` function would be called inside the implementation of the transform, precluding some optimisations and introducing risks of re-entrancy. For some transforms that trade-off might be worthwhile.

> Not having up-to-date example code is a pretty bad smell.

Indeed. I will let you know when they are updated.

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