Re: [webrtc-insertable-streams] Should we rename SFrameTransform and RTCRtpScriptTransform (#65)

> For instance, [pipeThrough](https://streams.spec.whatwg.org/#rs-pipe-through) first parameter name is 'transform'.

True, though I don't know how much to infer from typeless argument names. It looks like the streams spec has specifically [blessed](https://streams.spec.whatwg.org/#ts-model) the name "stream" for arguments to both `pipeThrough` _and_ `pipeTo`, even though their (duck) type signatures are entirely different. E.g.
```js
await src.pipeThrough(a).pipeThrough(b).pipeTo(c); // a, b and c are "streams" (but really only c)
```

> it does not create or consume data, it transforms data.

Or even transforms a stream of data? @domenic any comment on which naming strategy we should follow? 

> see https://w3c.github.io/webrtc-insertable-streams/#sframe-transform-algorithm

Ah, I missed that. But `frame.[[rtcObject]]` appears undefined. Should it be `frame.[[owner]]`?

> The 'role' is only used when using SFrameTransform as part of a JS-based pipe

I worry this is too clever and defeats encapsulation, composition, and early error detection. E.g. are you saying the following would work as long as `foo` is undefined?
```js
onrtctransform = async ({readable, writable}) => {
  const sframe = new SFrameTransform({role: "decrypt"});
  if (foo) {
    readable = readable.pipeThrough(foo);
  }
  await readable.pipeThrough(sframe).pipeTo(writable);
}
```
I think it would be better to explicitly have a `SFrameDecrypterStream` class and throw early if JS tries to use it on a sender. This would also match how we do encoding/decoding and compression/decompression.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-insertable-streams/issues/65#issuecomment-792837492 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 8 March 2021 15:36:56 UTC