Should we rename SFrameTransform and RTCRtpScriptTransform

[youennf]

And also RTCRtpScriptTransformer

[youennf]

@alvestrand mentionned we could find better names.
@jan-ivar mentioned that transforms are called streams in various specs.

[jan-ivar]

Firstly, the streams spec is particular about what can be called "streams", so we should use "stream" when it fits.

Secondly, transform streams in the platform seem come in pairs:

TextEncoderStream includes GenericTransformStream;
TextDecoderStream includes GenericTransformStream;

CompressionStream includes GenericTransformStream;
DecompressionStream includes GenericTransformStream;

To follow that would mean changing from:

SFrameTransform includes GenericTransformStream;

...to

SFrameEncrypterStream includes GenericTransformStream;
SFrameDecrypterStream includes GenericTransformStream;

This seems more ergonomic in JS. E.g. instead of

transceiver.sender.transform = new SFrameTransform();
transceiver.receiver.transform = new SFrameTransform({role: "decrypt");

...we'd avoid the boolean arg and just have:

transceiver.sender.transform = new SFrameEncrypterStream();
transceiver.receiver.transform = new SFrameDecrypterStream();

[youennf]

Currently, one can simply write:

transceiver.sender.transform = new SFrameTransform();
transceiver.receiver.transform = new SFrameTransform();

The 'role' is only used when using SFrameTransform as part of a JS-based pipe (see https://w3c.github.io/webrtc-insertable-streams/#sframe-transform-algorithm).

I am not a big fan of XXStream names for transforms.
For instance, https://streams.spec.whatwg.org/#rs-pipe-through first parameter name is 'transform'.
And that makes sense since it clarifies what it does: it does not create or consume data, it transforms data.

SFrameTransform mirrors well RTCRtpSender/RTCRtpReceiver 'transform' attribute name.
I would find it odd to rename sender.transform to sender.stream.
sender.transformStream would probably be ok but seems long and unnecessary precise.

[jan-ivar]

For instance, pipeThrough 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 the name "stream" for arguments to both pipeThrough and pipeTo, even though their (duck) type signatures are entirely different. E.g.

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?

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.

[domenic]

I like the SFrameEncrypterStream / SFrameDecrypterStream naming; it seems to match the other pairs of transform streams on the platform.

[youennf]

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

Right, I should fix that.

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?

That should work too given how insertable stream pipeline and data is bound to an owner.

I would like to get a full proposal here for SFrameTransform, RTCRtpScriptTransform, RTCRtpSender.transform and RTCRtpReceiver.transform. I would first judge on consistency inside the spec, then consistency with other specs.

Funnily, we seem to lean towards removing stream from the title of the spec.

[youennf]

Also in scope: RTCRtpScriptTransformer and DedicatedWorkerGlobalScope.onrtctransform

[youennf]

Too late for renaming, closing