- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 08 Mar 2021 15:36:55 +0000
- To: public-webrtc-logs@w3.org
> 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