Update endpoint pair example and fix citation #1318
Conversation
| readable.pipeThrough(new TransformStream(...)).pipeTo(writable); | ||
| async function handleTransformer({readable, writable}) { | ||
| await readable.pipeThrough(new TransformStream(...)).pipeTo(writable); | ||
| } | ||
| </xmp> |
There was a problem hiding this comment.
This example has been simplified a bit too much I think. It talks about a platform-provided Transformer interface but that interface is now super-implicit, because of the destructuring of function arguments. I think reverting to something like
const { readable, writable } = createTransformer();
readable.pipeThrough(new TransformStream(...)).pipeTo(writable);would work better.
Additionally, the point of createEndpointPair() was to match the official name given in the standard, "endpoint pair". So I think that that was even better.
Can you say more about why you changed this example?
There was a problem hiding this comment.
I read "web-platform-provided function createEndpointPair()" as a callout to the same-shaped sender.createEncodedStreams() method removed in w3c/webrtc-encoded-transform#64.
I was trying to maintain this similarity to the API it's referencing. But the spec's worker-only API is different. From MDN and blog post examples:
// main.html
const worker = new Worker("worker.js");
sender.transform = new RTCRtpScriptTransform(worker);
// worker.js
onrtctransform = async ({transformer: {readable, writable}}) => {
await readable.pipeThrough(new TransformStream(...)).pipeTo(writable);
};The spec fires an event with the transformer which has no constructor. The event part seemed unnecessary but I can try to add it if the context is useful.
There was a problem hiding this comment.
Sorry, this seems to have gone in the opposite direction of what I'm requesting. The point of this example is not to reference any other API. (That's the purpose of the note below, which you helpfully edited for accuracy.) It's to give an example of the simplest possible concept of an endpoint pair, i.e. a platform-provided API that returns a { readable, writable } object.
The naming is especially important, as we're trying to illustrate the "endpoint pair" concept defined above, not some sort of "transformer" concept which this document does not define.
Can you revert it to its previous version?
Fixes #1317 (editorial).
Preview | Diff